Re: [pylons-devel] correct way to close a sqlalchemy session?

[Jonathan Vanasco]

> On Wednesday, April 6, 2016 at 8:14:02 PM UTC-4, Jeff Dairiki wrote:
>>
>> Maybe that's enough motivation to go that way? 
>>
>
Ok. I lasted a full week using the global scoped session and just couldn't 
do it anymore. 

Back to my old way / the new way.   I updated the project to use the 
forthcoming template and no longer want to stab people in the eye.

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/pylons-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [pylons-devel] correct way to close a sqlalchemy session?

[Jonathan Vanasco]

On Wednesday, April 6, 2016 at 8:14:02 PM UTC-4, Jeff Dairiki wrote:
>
>
> I'm not very familiar with the stock scaffold.  I just went to look at it 
> and was initially confused, since the scaffold in the master branch 
> currently uses a reified request property to construct the SqlAlchemy 
> session (without a global scoped session).  (See models/__init__.py 
> .)
>  
>  Maybe that's enough motivation to go that way?
>

That's odd.  I did some digging in github, and that's tied to some 
forthcoming/development approaches on changing all the scaffolds..

The "classic" method is in the active branch (and leading up to it)

  
https://github.com/Pylons/pyramid/blob/1.6-branch/pyramid/scaffolds/alchemy/%2Bpackage%2B/models.py

 

> Of course, either will work.  FWIW, of the two, I'd vote for the tween — 
> the logic seems clearer to me, not that either is a brain-twister.
>
 

I'll stick with the tween for now; it'll be too much work to convert to the 
'right' system.

I *did not* like using the scoped DBSession approach, but it matched the 
current Pyramid docs and tutorials.

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/pylons-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [pylons-devel] correct way to close a sqlalchemy session?

[Jonathan Vanasco]

I edited my original post before hitting submit, and managed to clear out 
the important stuff.  Ha.

On Wednesday, April 6, 2016 at 2:42:38 PM UTC-4, Jeff Dairiki wrote:
>
> I use a reified request property to create the SqlAlchemy session. 
> The factory function adds an "add_finished_callback" to close the session.


I do that in all my personal/work apps.
Right now, I'm using the stock scaffold with global scoped session for a 
side project that I'm open sourcing.

 

>   (Why don't you have access to the request?)
>

I'm trying to keep things simple and do this in app/__init__.py.

the `main` function only has a config object, the request doesn't exist yet.

def main(global_config, **settings):
config = Configurator(settings=settings)
wsgi_app = config.make_wsgi_app()
return wsgi_app

so I need to somehow use a hook that has a request object.  two things that 
came to mind:  tweens and events.


def db_cleanup__tween_factory(handler, registry):
def db_cleanup__tween(request):
try:
response = handler(request)
return response
finally:
DBSession.close()
return db_cleanup__tween

def db_cleanup__event(event):
event.request.add_finished_callback(lambda request: 
DBSession.close())

def main(global_config, **settings):
...
config.add_tween('app.db_cleanup__tween_factory', over=EXCVIEW)
config.add_subscriber("app.db_cleanup__event", 
"pyramid.events.NewRequest")
...




-- 
You received this message because you are subscribed to the Google Groups 
"pylons-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/pylons-devel.
For more options, visit https://groups.google.com/d/optout.

[pylons-devel] Re: request context for Sentry

[Jonathan Vanasco]

On Wednesday, March 16, 2016 at 9:36:44 PM UTC-4, Zsolt Ero wrote:
>
> David Cramer from Sentry replied to me that if Sentry is used with the 
> middleware, then it should automatically receive the WSGI context:
> from sentry.middleware import Sentry
>
> application = Sentry(application, client=Client(dsn, ...))
>
> My problem is that in Pyramid I have no idea where could I get an 
> application, or if this would work at all.
>

That looks like the initial app setup in your `project/__init__.py`

`application` would be what is returned from config.make_wsgi_app()

Some people do "return config.make_wsgi_app()"

Others prefer "app = config.make_wsgi_app()", then wrap it in middleware


-- 
You received this message because you are subscribed to the Google Groups 
"pylons-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/pylons-devel.
For more options, visit https://groups.google.com/d/optout.

[pylons-devel] Re: Setting translogger format via ini

[Jonathan Vanasco]

Assuming the issue is what you think it may be...

What if you just used the .ini file to declare that you want translogger 
enabled and some variables, but then your app setup code handles the setup 
(and fixes the template line). 

That would still let you control everything off an ini, but your code would 
do the integration instead of paste.

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/pylons-devel.
For more options, visit https://groups.google.com/d/optout.

[pylons-devel] Re: PasteDeploy in the Pylons GitHub org?

[Jonathan Vanasco]

Assuming (1) Ian isn't going to maintain it anymore, (2) You have his 
blessing as the new maintainer [but want to push this off]...

You may be speaking about this, but if not...

Have you considered an approach like starting a new github organization for 
pastedeploy (or paste) ?  That would make the "official" home for the 
project something like "github.com/pastedeploy/pastedeploy" (instead of a 
repo under your account) and allow for the ownership to be handed off 
without the core url changing again.


-- 
You received this message because you are subscribed to the Google Groups 
"pylons-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/pylons-devel.
For more options, visit https://groups.google.com/d/optout.

[pylons-devel] Re: Adding custom properties to the request, or how is the request meant to be used?

[Jonathan Vanasco]

Read the docs on `add_request_method`.  It's pretty great.  I think the 
docs continue on the set property method, and explain the pattern a bit 
more.

Anyways, combined with reify, there is very little overhead.  You can also 
use dotted-name strings to register, which can make things a bit easier for 
writing extensions/plugins.

Just to clarify my earlier point: If you were merely building your own 
application, I would do everything on the request itself.  Since you're 
building/maintaing a framework though, I think you may be better off with 
your own "context" objects that gets tossed onto the request.  That could 
give you better control of modules/plugins registering with your 
application.  

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/pylons-devel.
For more options, visit https://groups.google.com/d/optout.

[pylons-devel] Re: Adding custom properties to the request, or how is the request meant to be used?

[Jonathan Vanasco]

I have about a dozen reified request properties on an application.  They're 
great.

It's entirely possible to abuse it – but that's what coding standards are 
for.

We have about a dozen objects on our request.  They could be consolidated 
into a smaller, nested, hierarchy... but they're all "request specific".  

A few of our properties are documented as "public" – and ensured to work 
across our application.  A few of them are documented as "private" -- 
they're enabled(registered) by a single component that may or may not be 
enabled.  No code outside that component can touch it.   (for example, our 
caching layer and some environment-specific debugging).

Pyramid's implementation of add_request_method + reify meant there's 
virtually no overhead during runtime (95% of them are never called during a 
request).  We could have created a singular "api" namespace, but then we 
would need to re-implement the add_request_method for registration and 
management.  That seemed onerous.

Looking at the example you gave, since you're doing this on a framework, I 
think it would be a bit different.

Personally, I would create a reify'd '.ringo' property on each request for 
the "public api" (and possibly use `_ringo` for non-public/core usage).  I 
would have that property be a request-specific context object. 
 `request.features.FOO` could be a way to handle the 
`request.registry.settings` data.  functions could then either rely on 
`request.ringo` or be invoked with the context object as an argument.  

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/pylons-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [pylons-devel] Best Practices with ORM use

[Jonathan Vanasco]

In my experience, the standard scaffold way is perfect for most uses.

If your codebase grows very large, or you start needed to run non-pyramid 
services, you may need to rethink things.

One of my projects outgrew the typical 'views' approach.  Now, we prototype 
the functionality onto the views but then create functions that do all the 
real work in a `lib.api` namespace.  The views just format data for the 
internal api and pass in the right arguments.  The main reason why migrated 
to this approach, is that a lot of shell scripts / celery functions / 
twisted functions (and some microservices tested out in flask) were all 
needing to do the same things.  Now we just import a core library that has 
the models and api into whatever application.

Just to be a bit more clear, in our approach:

* pyramid + view = validate form data, handle form responses, decide what 
to query/insert/update/etc
* model + api = accepts formatted args and connections to database + 
request/caching layer for routine tasks.

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/pylons-devel.
For more options, visit https://groups.google.com/d/optout.

[pylons-devel] Re: github pages for pylons project sites

[Jonathan Vanasco]

I just wanted to add that PylonsHQ redirects to PylonsProject (and is the 
name of the github project), and that link should be maintained.

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/pylons-devel.
For more options, visit https://groups.google.com/d/optout.

[pylons-devel] Re: Deployment with supervisor + ZEO

[Jonathan Vanasco]

What does "zeo storage fails" mean?  Is the service not starting, is 
pyramid not connecting to it?

Have the logs suggested anything ?

Anyways, I'm unclear if there is a race condition involved between the 
storage engine and your pyramid app.  If pyramid needs the storage engine 
to start up, and thereby needs to run AFTER zeo (I assume this might be 
happening), then you can use a `priority` config setting on each app to 
affect the startup/shutdown order.


-- 
You received this message because you are subscribed to the Google Groups 
"pylons-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/pylons-devel.
For more options, visit https://groups.google.com/d/optout.

[pylons-devel] including debugtoolbar support in plugins

[Jonathan Vanasco]

This is a bit of a pie-in-the-sky idea...  but it occurred to me the other 
day that there should be a standard way of organizing/packaging plugins 
that provides for debugtoolbar support.

i.e., a standard style for creating a plugin that also has a debugtoolbar 
panel (or other hook into the toolbar).  

I don't think this would require any changes to the api, it would just be 
an "official" standard for writing plugins.

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-devel.
For more options, visit https://groups.google.com/d/optout.

[pylons-devel] Re: Scripting requests - Pyramid + Celery

[Jonathan Vanasco]

What exactly are you trying to do with Celery - can you give an example?

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [pylons-devel] Re: Scripting requests - Pyramid + Celery

[Jonathan Vanasco]

Ok, this use case is somewhat similar to ours... in that it doesn't require 
pyramid at all.  We use sqlalchemy, but zodb shouldn't be much different.

We have 2 packages:

* `myapp_pyramid`
* `myapp_celery`

`myapp_pyramid` will import `myapp_celery` to call it's `@task` decorated 
functions.  these functions are just a workhorse.

`myapp_celery` is also invoked as a worker daemon.  it imports 
`myapp_pyramid`, but only to use the models and some library utilities. 
 (in a more perfect world, the models would be in a third package).  

each celery `@task` starts/manages it's own transaction and database 
connection.  it doesn't run any pyramid code, and isn't bound to a request 
or anything like that.  

quick sidenote, if you think there is a memory leak -- are you running 
debugtoolbar?  that stashes the requests, so the process will keep growing 
and it will look like a memory leak... but it's really a conscious decision 
to keep the memory.

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [pylons-devel] Re: wsgi server of choice?

[Jonathan Vanasco]

For development I use nginx on http/https default ports, serving static 
directly and proxypass back to pserve for dynamic content.
The staging/production environment just swaps out the proxypass for uwsgi.

Everything in nginx is built out with components/includes, so it's 
literally just swapping out a block that handles certain routes.  That 
really minimized issues between environments.

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [pylons-devel] wsgi server of choice?

[Jonathan Vanasco]

On Thursday, September 24, 2015 at 12:28:01 PM UTC-4, Bert JW Regeer wrote:
>
> I personally use uWSGI with nginx, however there are also a lot of people 
> that simply reverse proxy to waitress. 
>

Production: uWSGI with nginx.  nginx is controlled by the standard os 
hooks; the uwsgi services are controlled by supervisord.

Development: waitress with nginx.

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [pylons-devel] Testing a Pyramid app with Jenkins

[Jonathan Vanasco]

I wouldn't run this via supervisord, because supervisord is really aimed at 
managing services that are supposed to be "on" (ie, production or staging 
environments).  You'll encounter a lot of issues when you need to persist 
an off-state across reboots or need to tweak certain settings (which will 
force all supervisord managed services to shut-down then start up again).

It also sounds like you're trying to just keep a version of the app running 
online somewhere, then update that and run tests against it. 

Personally, I think it would make better sense to just spin up your demo 
app as a process that belongs to Jenkins, run the tests against that, and 
then shut it down -- all within your testrun.  This way your  tests are all 
isolated and ensured against that exact build.  If you want to keep a a 
staging or other live version, manage it separate depending on the outcome 
of tests -- If your tests pass, upgrade that app to the new version; if 
they fail, leave that last functional app as-is.


-- 
You received this message because you are subscribed to the Google Groups 
"pylons-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-devel.
For more options, visit https://groups.google.com/d/optout.

[pylons-devel] debugtoolbar - panel/toolbar API-- feedback wanted.

[Jonathan Vanasco]

I had an idea a while back for a Toolbar - Panel api, and I think I need 
to build it out.  hoping someone here can set me straight and offer some 
better ideas on how to pull this off.

The simple idea:
1.  Give each panel a `toolbar` attribute after instantiation.  this 
would allow any panel to loop through the toolbar's panels, and access the 
information on another one.  
2.  add a config.scan in __init__.py for panels/

Why?
The toolbar panels generally work by stashing a lot of information on 
the request object, this is a lot of great info -- but only accessible to 
the panel itself.  If panels could find one another (and a new view could 
be added), it would be trivial to do things like creating an API endpoint 
that can pull that data out.

This is my practical use-case example:  The unit test that ensures all my 
routes work also times the pages; a few pages have shown troubling times 
and I need to inspect them.  Just about all the information I need is in 
the Performance and SqlAlchemy panels.  It would be fairly simple to 
piggyback on all the work done by the debugtoolbar team, and simply parse 
the pDebug link from the response, then have a followup request pull the 
data from an endpoint and save it to a text file.  

-- 
You received this message because you are subscribed to the Google Groups 
pylons-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [pylons-devel] debugtoolbar - panel/toolbar API-- feedback wanted.

[Jonathan Vanasco]

Nice!

I'm just looping panels right now with isinstance() to discern the correct 
one.

It took a while to get the config right, but I was able to implement this 
without any edits to debugtoolbar yet.

https://github.com/jvanasco/pyramid_debugtoolbar_api_sqla

-- 
You received this message because you are subscribed to the Google Groups 
pylons-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-devel.
For more options, visit https://groups.google.com/d/optout.

[pylons-devel] Re: pcreate: Uppercase version of the package name?

[Jonathan Vanasco]

You might be able to use the Project variable, if you pass in a 
Capitalized form

$ pcreate --scaffold starter Foo
 'project': Foo,
 'package': foo,

Note that this doesn't Capitalize the name.  it keeps it as-is:

$ pcreate --scaffold starter FooBarBash
 'project': FooBarBash,
 'package': foobarbash,


Otherwise you'd have to patch or monkeypatch pcreate.py in order to do that:


https://github.com/Pylons/pyramid/blob/master/pyramid/scripts/pcreate.py#L106-L112

-- 
You received this message because you are subscribed to the Google Groups 
pylons-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [pylons-devel] suggestion - internal lifecycle logging

[Jonathan Vanasco]

On Thursday, October 2, 2014 11:01:33 PM UTC-4, Bert JW Regeer wrote:

 This seems like functionality that any ol’ profiler should be able to give 
 you, and wouldn’t require any changes in Pyramid. 


Mostly, yes.  For my personal needs, I can backtrack data out of this on my 
dev environment via the profiler integration on debug_toolbar.   I could 
probably do this on production using repoze.profile as Tres suggested. 
 It's worked well enough, but a bit of a pain.

I was just thinking about the community needs though.  The profiler 
information doesn't map to any sort of lifecycle data.  using the 
debug_toolbar as an example -- the most standard data you can find is 
`pyramid/router.py:66(handle_request)`.  Because pages could be rendered 
different ways (view_config, render_to_response, etc), there is no one-size 
fits all solution.  All other calls are either developer code or various 
supporting library functions that don't map to any specific business logic. 
 application profiling is, essentially, a highly customized task.

if there were some sort of internal reporting at key request lifecycle 
events, then high-level application profiling would be fairly standardized. 
 it would be easy to see that a bottleneck was in the view, the database, 
the template or auth.  

-- 
You received this message because you are subscribed to the Google Groups 
pylons-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-devel.
For more options, visit https://groups.google.com/d/optout.

[pylons-devel] suggestion - internal lifecycle logging

[Jonathan Vanasco]

When doing performance audits, an annoying feature of Pyramid is that it's 
not very easy to pinpoint where the slow part is.

I'd like to suggest some sort of logging facility for the internal request 
lifecycle

there are a handful of things that I think could provide useful metrics, 
either displayed via a debugtoolbar widget, or logged elsewhere via tween. 
 i don't think this would be possible without hooks directly into pyramid 
though.

off the top of my head, these are the things I think would be useful:

- time spent on request setup (parsing cookies, loading sessions, etc)
- time spent on auth decorators
- time spent within a request dispatch
- time spent within pyramid.renderers functions

while time spent within a request would be inclusive of rendering, it would 
be simple to subtract the rendering time
time spent on rendering calls would probably need to be logged as an array 
(it's possibly to have multiple calls to `render`)

the reason why this is something that i'm interested in, is that the 
various templating languages currently supported by pyramid allow raw 
python, so it's possible for slow or blocking code to sneak into them.

i just wanted to start some dialog or brainstorming on this.

-- 
You received this message because you are subscribed to the Google Groups 
pylons-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-devel.
For more options, visit https://groups.google.com/d/optout.

Re: Pyramid Design Question

[Jonathan Vanasco]

Honestly , It depends on how you see the application grow.

I've been doing more of Choice D lately-

Choise C - Keep that stuff in the View.
Choice D - Have an internal API for methods like getAllComments; 
exposing something like lib.internal_api.getAllCommentsForBlogentry(id)

For preliminary views and admin work, using SqlAlchemy with only mapped 
relations and association proxies has been perfect.  

Something that really made us want to keep the  Model slimmed down , and 
transition logic into views/libs , is that we re-use our core SqlAlchemy 
model across different services [ currently Celery and Twisted ].  If we 
had more logic in the model, we'd have to maintain it across multiple 
environments AND have a bit of memory bloat.  So we've kept SqlAlchemy 
classes to only handle the core model ( columns and relations ).

As our application advances, we've run into problems with Performance 
Tuning, Result Pagination and Caching.  We found it easier to implement a 
Read-Through cache with a customized solution , where 'public' objects are 
pulled from a cachingAPI that fails onto our internal API.  The internal 
API mainly queries PostgreSQL, but the underlying datastore for different 
objects -- or functions -- can be swapped or even mixed. The results we 
return are always interchangable with SqlAlchemy objects, so the code 
outside of lib never changes from this type of stuff.

For 95% of apps, you won't need stuff like that.  Thankfully Pyramid lets 
us.

-- 
You received this message because you are subscribed to the Google Groups 
pylons-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-devel.
For more options, visit https://groups.google.com/groups/opt_out.

is the current sqlalchemy scaffold 'correct' ?

[Jonathan Vanasco]

Someone posted a docs suggestion to -devel, which made me look at the 
current sqlalchemy scaffold.


I'm not sure it's 'correct' 


a few weeks ago I asked Mike Bayer (sqlalchemy) what the best practices for 
webapps were ( 
https://groups.google.com/forum/#!topic/sqlalchemy/ZsHxDzlATCQ )


he responded with two links:


fairly recently i wrote up as much as I could come up with on this, which 
 you can see first in the Session FAQ:

 http://docs.sqlalchemy.org/en/rel_0_8/orm/session.html#session-frequently-asked-questions


 and then regarding scoped_session in:

 http://docs.sqlalchemy.org/en/rel_0_8/orm/session.html#using-thread-local-scope-with-web-applications
  



the big thing that i'm picking up off the current scaffold, is that there's 
a single scoped_session as DBSession in models.py ( 
https://github.com/Pylons/pyramid/blob/master/pyramid/scaffolds/alchemy/%2Bpackage%2B/models.py_tmpl
 
) , while the views.py uses that same session ( 
https://github.com/Pylons/pyramid/blob/master/pyramid/scaffolds/alchemy/%2Bpackage%2B/views.py_tmpl
 
)

the scaffold seems to not invalidate the local sqlalchemy session , or 
suggest that a new one is created.

It's my understanding that a few things should happen instead ( which are 
basically covered in the cookbook )


a) if a 'global' `DBSession` is used within a view, is should be explicitly 
instantiated to create a new thread/request local instance `DBSession()`

and/or

b) you could opt to be even more explicit and use tween to prep the session 
( or use add_request_property ) -- but that setup action should also run a 
add_finished_callback to `remove` (invalidate) the session after the 
request.


in pseudocode , something like

def ScopedSession_cleanup(request):
 request.ScopedSession.remove()

def tween_factory(handler, registry):
def tween(request):
  request.ScopedSession = ScopedSession()
  request.add_finished_callback(ScopedSession_cleanup)
return tween

getting to the nuts and bolts:

1- 
http://docs.pylonsproject.org/projects/pyramid_cookbook/en/latest/database/sqlalchemy.html#using-a-non-global-session

def cleanup(): would be better to have `session.remove()`, not 
`session.close()`

2- 
https://github.com/Pylons/pyramid/blob/master/pyramid/scaffolds/alchemy/%2Bpackage%2B/views.py_tmpl

 bad :
   one = DBSession.query(

 better :
local_session = DBSession()
local_session.query(

it might also make sense to replace `DBSession` with `DBSessionFactory`.  

thoughts ?



-- 
You received this message because you are subscribed to the Google Groups 
pylons-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Alternative Licensing Request ?

[Jonathan Vanasco]

Does anyone know how / where I can request an alternate licensing 
permission ?

I'm trying to create a new Session package that replaces most of beaker 
with a dogpile backend.

Dogpile and Beaker both have the BSD license.  pyramid_beaker is under the 
bsd-like Agendaless Consulting license ; and I'm retaining a large section 
of __init__.py .  I'd prefer (if at all possible) to just use the BSD 
license and credit Agendaless/pyramid_beaker

-- 
You received this message because you are subscribed to the Google Groups 
pylons-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Wanted: HTML tag generator for WebHelpers2

[Jonathan Vanasco]

On Friday, June 28, 2013 5:04:08 PM UTC-4, Mike Orr wrote:


 Are there any other syntactic sugar patterns that would be helpful in a 
 Javascript-rich or HTML 5 application?


you should support html5 custom data attributes , the *data-** syntax.  

ie:
a href=http://example.com; data-a=1 data-b-a=2Link to 
Example.com/a

you can have one (or more) dashes in them, so I'm not sure how you could 
pass them in , other than as a dict

make_tag(... attrs={ 'data-a' :1 , 'data-b-a':2 }... )
make_tag(... data_attrs={ 'data-a' :1 , 'data-b-a':2 }... )
make_tag(... data_attrs={ 'a' :1 , 'b-a':2 }... )

personally i would prefer one of the first two options; i'm only bringing 
up the last one to note my disapproval of it.

-- 
You received this message because you are subscribed to the Google Groups 
pylons-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-devel.
For more options, visit https://groups.google.com/groups/opt_out.

question about design decision on pyramid's core

[Jonathan Vanasco]

looking at the source, I see:

* pyramid/chamelon_text.py
* pyramid/chamelon_zpt.py
* pyramid/mako_templating.py

was there any reason for these being on the top-level, and not under a
consolidated namespace like pyramid/templating  , or did this just
happen randomly ?

-- 
You received this message because you are subscribed to the Google Groups 
pylons-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: question about design decision on pyramid's core

[Jonathan Vanasco]

thanks. makes sense.

i'm just trying to reverse engineer some templating flowthroughs.
most other things were logically grouped together.

-- 
You received this message because you are subscribed to the Google Groups 
pylons-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: question about design decision on pyramid's core

[Jonathan Vanasco]

On Mar 27, 4:33 pm, Blaise Laflamme bla...@laflamme.org wrote:
 you're about t reverse-engineer mcdonc's brain... be careful ;)

ha!

i just needed to figure out the mako integration , which was pretty
straightforward ( see the other thread ).

-- 
You received this message because you are subscribed to the Google Groups 
pylons-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: choice of documentation license

[Jonathan Vanasco]

I'd suggest these 2 strategies:

1. Dual-License the Docs as a choice between Current or the Perl
Artistic license.  The Artistic license is OSI  Debian approved, but
neuters most commercial activities ( docs can be on retail CDs , but
books would fall under a reasonable copying fee ).

2. split the documentation into two distributions :
* API Documentation - Same license as Pyramid itself
* Narrative documentation - keep it as-is , possibly dual-licence as
above.  but i'd rather see it as-is for reasons below...

Debian's take on Free is unique.  With good rationale, they consider
even things like the GNU Free Documentation License to be non-free.
If the narrative docs are split off, they can still be in a non-free
repo.  Realistically, the overwhelming majority of people using the
docs are going to be interfacing with them online , or won't have an
issue downloading a new archive.

The narrative docs are great, and it would be sad to see someone
exploit them.   do people buy tech books anymore?  i'm worried more
about the companies that take free content, run SEO and SEM campaigns
against them, and make money off arbitrage.  i'd like to know that
when people search for something on Pyramid, they end up at the
official docs -- not some clone that is exploiting it.

-- 
You received this message because you are subscribed to the Google Groups 
pylons-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

routing syntax is a bit weird

[Jonathan Vanasco]

just an observation

i had an issue with route matching, due to my error of not having a
proper regex in the route

/archive/{}/{mm}/{dd}/{slug}

was quickly fixed with:

/archive/{:\d{4}}/{mm:\d{2}}/{dd:\d{2}}/{slug}

does anyone else think that this syntax is weird?  shouldn't the
grouping brackets have been different than regex brackets, since regex
can be used to better specify routes  ?  ( or even just used a real
regex on the route ? )

-- 
You received this message because you are subscribed to the Google Groups 
pylons-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: how are the pyramid docs managed ?

[Jonathan Vanasco]

On Feb 8, 3:46 pm, Blaise Laflamme bla...@laflamme.org wrote:
 Hi jonathan,

 feel free to modify the sphinx theme and send a pull request. Actually
 older versions like 1.1, 1.2, etc, are not out-of-date but up-to-date with
 those versions. There are the latest and the development one that reflects
 the current stable and development versions of Pyramid. A mention to point
 to other versions would be good, I'm also working on a new theme that would
 include this information, and others tricks, but it's not ready ;) I hope
 to use the pycon sprints to work on this.

is the new theme online anywhere ?

i'm largely concerned with SEO tricks and just some visual cues going
oh hey, this is/might be out-of-date.

For example, if I search for pyramid.request on a major engine, I
get a mix of -latest and 1.x docs.

What I'm thinking might work is this...
- since the theme is an external repository, have it reference back to
the pyramid/master ( hopefully that wont have a recursion issue?
otherwise to another repo ) to check what the current master/latest
and legacy versions are
- docs would contain , at the header, a note like this:
   you are viewing the most current Pyramid docs, for the 1.4 branch.
if using an earlier branch, please click here. 
   you are viewing the legacy Pyramid docs, for the 1.0 branch. if
you are using a new branch, please click here.
  ( basically a better version of this page : http://httpd.apache.org/docs/1.3/
)
-  every page would also contain a link to the /latest branch, to push
up the internal pagerank for the domain
- all the versioned docs push a link rel=canonical href=/latest/

using that, we should effectively eliminate all of the 1.x items from
google/yahoo/bing search , and everything will point to /latest ...
with the per-version docs easily accessible




-- 
You received this message because you are subscribed to the Google Groups 
pylons-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: how are the pyramid docs managed ?

[Jonathan Vanasco]

On Feb 9, 2:21 pm, Blaise Laflamme bla...@laflamme.org wrote:
 No the new theme is not online, I've been just playing with different ideas
 before starting the public project. The current theme is
 here:https://github.com/Pylons/pylons_sphinx_theme

 Do you attend pycon this year?

Sadly no, I have a few conflicting biz meetings :(

-- 
You received this message because you are subscribed to the Google Groups 
pylons-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

how are the pyramid docs managed ?

[Jonathan Vanasco]

what controls how the pyramid docs get built and stored onto
doc.pylonsproject ?

looking at the github source ( 
https://github.com/Pylons/pyramid/tree/master/docs
) it looks to me like only the current docs are in master, and the
older ones are built off misc releases

the reason why i ask, is that i wanted to try and patch the templates
to add some SEO tricks and also an alert box that appears on specific
version branches, and lets people know that the docs are ( or may be )
out of date -- and pointing to the latest release.

i've referenced out-of-date docs a few times from search engines
myself, and i've seen many others with the same issues.  would love to
stop it.

-- 
You received this message because you are subscribed to the Google Groups 
pylons-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Suggestion for Request namespace provisioning

[Jonathan Vanasco]

The past few updates to Pyramid have had a few changes around the
Request object - new attributes, new functionality to add attributes,
etc.

With that, combined with the best-practice of passing the Request
object around during the request lifecycle,   I wanted to suggest
creating a 'project' and 'plugin' namespace under request , so that
(moving forward) as people develop plugins or write app specific
request attributes there is no issue for collision against each other
or future Pyramid releases.

The general idea would be this:
   request.project = reserved for your app ( or
request.projects.project_name ).  do what you want.
   request.plugins = reserved for plugins that need to attach data to
the request object.  ex: request.plugins.sqlalchemy

The main idea is that instead of using 'set_property', you'd use
'set_project_property' or similar.  Not suggesting that we drop the
current scenario, just that
- the request object has a lot of stuff in it now
- i can see the request object's attributes/methods growing as Pyramid
matures
- i fear namespace collision.

-- 
You received this message because you are subscribed to the Google Groups 
pylons-devel group.
To post to this group, send email to pylons-devel@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-devel+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-devel?hl=en.

Re: Suggestion for Request namespace provisioning

[Jonathan Vanasco]

That pattern / functionality is great.  I'm just talking about
proactively saying this name space is reserved for plugins, this
namespace for projects - you can rest assured that as Pyramid grows
and new functionality is added, you will not be affected as long as
you stay within that container.  Right now, request.foo is a bit of a
lottery -- from my perspective, chances are you won't add anything to
Pyramid over there, but its not an explicit/futureproof property.

-- 
You received this message because you are subscribed to the Google Groups 
pylons-devel group.
To post to this group, send email to pylons-devel@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-devel+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-devel?hl=en.

Re: AuthTktAuthenticationPolicy using MD5

[Jonathan Vanasco]

 Additionally you could provide help on how to generate such a secret (but 
 that's extra candy). I have looked through various parts of the 
 documentation and it is always set to something like 'seekrit' and similar, 
 but it is never mentioned how to make sure that this is secure.


fwiw, wordpress has had this feature for a while: the docs instruct you to 
visit the following url , which generates valid secret strings.
 http://api.wordpress.org/secret-key/1.1/

i think most of the application scaffolds will generate a secret - but it 
might be useful feature to just have a secret-key generator on 
the pylonsproject.org site and referenced in the docs.

I've also generally disliked the mod_authtkt for a few years. i've opted 
for an approach where the secret rotates based on the timestamp and/or 
ip/other data.  it's a bit harder to set up in a clustered environment, but 
the tickets are HMAC with SHA512 with rotating keys.  it doesn't make it 
unbreakable, but just a bit more of pain to break and with some sort of 
timed window before you need to break it again.

-- 
You received this message because you are subscribed to the Google Groups 
pylons-devel group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/pylons-devel/-/4dxNXUSoAPAJ.
To post to this group, send email to pylons-devel@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-devel+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-devel?hl=en.

pyramid_mailer / repoze.sendmail - doc issues and new functionality

[Jonathan Vanasco]

I went a bit crazy the other day dealing with pyramid_mailer

after going through all the code for pyramid_mailer and
repoze_sendmail , I realized that the send_to_queue function occurs
within the transaction.

this isn't mentioned anywhere within the docs and it is described in a
section /after/ the send_immediately functionality is discussed...
which would lead one to believe that it is not transaction safe.

that being said , i'd like to request a docs change to note that.

it would also be nice if there was a send_immediately_to_queue
function ( ie, not transaction safe ) -- but that code is too much for
me to jump around in.   i should also note that messages are tossed
into a /tmp folder within the maildir until the transaction is done
for delivery. if the transaction is not commited, they just seem to
pile up.  ( note: i run pyramid without transactions so this might be
the cause of that.  if so, perhaps only a note is needed. )

i created a quick package called pyramid_sendmail (
https://github.com/jvanasco/pyramid_sendmail and on pypi )

it extends the repoze.sendmail and pyramid_mailer functionalities with
an actual sendmail delivery mechanism.  i formatted the package into
files that are named to indicate which packages they are extending.
[ staring with p_ pyramid_mailer and r_ repoze.sendmail  ; and the
'suffixes' are a 1:1 naming with the files that the content would
appear in ]

i didn't build tests or anything onto this, because I only need it for
a single use-case.  piping message to sendmail is really useful though
-- and supported by most frameworks and platforms -- so i figured I
could implement it in a way that would give a head-start to upstream
support.

-- 
You received this message because you are subscribed to the Google Groups 
pylons-devel group.
To post to this group, send email to pylons-devel@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-devel+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-devel?hl=en.

Pylons Website Requests

[Jonathan Vanasco]

A couple of small requests for the website after trying to jump on it
to view source :

- The first slide on the splash screen is for a Download.  It would
be great if there was a GitHub link on that too.
- It would be great if the projects pages had links to github as
well
- Finally, it would be great if there were a Download nav item
( which can just link to existing pages / sections )

-- 
You received this message because you are subscribed to the Google Groups 
pylons-devel group.
To post to this group, send email to pylons-devel@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-devel+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-devel?hl=en.

Documentation Suggestions for Subscribers or Debug

[Jonathan Vanasco]

I ran into an issue a few months ago regarding a NewResponse
subscriber and failing to catch errors (
https://groups.google.com/group/pylons-discuss/browse_thread/thread/54b5b3eb5e2ccfe/4e9a2abc09b9651f
)

As I prepare for a production release , my old code ( which i forgot
to remove ) started firing -- and I finally figured out what was
happening.

Because I had debugging turned on via 'development.ini', Pyramid was
catching the error  response object from the app, and replacing it
with its own.

In a perfect world, the Pyramid debug system would let the original
response/request stuff somehow persist -- so code can be written that
works on production and development.

In a less perfect, though perfectly acceptable world, it would be
great if the debug  event subscriber docs cross-referenced one
another with an alert/note box that simply states that the debug
system will 'overtake' the response object when turned on, and
subscribers that are designed to handle errors may not work as desired
when debugging is enabled.

-- 
You received this message because you are subscribed to the Google Groups 
pylons-devel group.
To post to this group, send email to pylons-devel@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-devel+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-devel?hl=en.

Re: Small Pyramid Prototype on PyPi (might be helpful for someone starting out)

[Jonathan Vanasco]

i built a non-cms thing a few weeks back , to illustrate how a bunch
of packages i wrote work.

   http://github.com/jvanasco/pyramid_packages_demo

there might be some stuff in there that helps you.

-- 
You received this message because you are subscribed to the Google Groups 
pylons-devel group.
To post to this group, send email to pylons-devel@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-devel+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-devel?hl=en.

Re: finally it is done: web2pyramid (aka gluino)

[Jonathan Vanasco]

Check this tutorial
http://wiki.python.org/moin/CheeseShopTutorial

The general flow
1. Register your account on PyPi - 
http://pypi.python.org/pypi?%3Aaction=register_form
2. 'register' the package with pypi:  `python setup.py register`
3. 'upload' the package : `python setup.py sdist upload'

whenever you have updates , you just do step 3

-- 
You received this message because you are subscribed to the Google Groups 
pylons-devel group.
To post to this group, send email to pylons-devel@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-devel+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-devel?hl=en.

suggestion for scaffolds

[Jonathan Vanasco]

two quick suggestions for scaffolds.  i'd be happy to submit a patch
if the maintainers agree:

1. Move cache_max_age to a dev.ini setting

scaffolds currently have this line:

https://github.com/Pylons/pyramid/blob/master/pyramid/scaffolds/alchemy/%2Bpackage%2B/__init__.py
https://github.com/Pylons/pyramid/blob/master/pyramid/scaffolds/starter/%2Bpackage%2B/__init__.py
https://github.com/Pylons/pyramid/blob/master/pyramid/scaffolds/zodb/%2Bpackage%2B/__init__.py
config.add_static_view('static', 'static', cache_max_age=3600)

That's great in production, but on dev you often need to test against
css/js/img changes

I found this approach works very well:
__init__.py
config.add_static_view('static', 'static',
cache_max_age=settings['static.cache_max_age'])
dev.ini
static.cache_max_age= 60

[ then i use 3600 on production.ini and 600 on staging.ini ]


2. migrate all the /static/ items to /static/pyramid/

it's too cluttered and slightly intimidating , and when you're playing
around... i want to clean out those files but I don't want to lose
them (yet).

-- 
You received this message because you are subscribed to the Google Groups 
pylons-devel group.
To post to this group, send email to pylons-devel@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-devel+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-devel?hl=en.

Re: Prototype works under Konqueror - jQuery ie - not

[Jonathan Vanasco]

just because these libraries are not being supported by the framework
doesn't mean that they're incompatible with the framework.

the pylons people are focusing on the backend framework , and simply
not trying to do the automagic integration points that generate
javascript code per-libary

you can still use prototype or any other libraries with pylons --
they're all 'compatible'.  you just have to write the javascript
yourself or write javascript generation bits yourself.

honestly though, writing something in jquery is often faster than
writing it in python ;)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
pylons-devel group.
To post to this group, send email to pylons-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/pylons-devel?hl=en
-~--~~~~--~~--~--~---