[pylons-devel] Re: ZODB transaction callback problem

[Jonathan Vanasco]

On Saturday, March 11, 2017 at 10:14:11 AM UTC-5, Robin Harms Oredsson 
wrote:
>
> The only pattern I've really found seems to be:
> - It always happens on aborts
> - It seems to be during some  server load
> - It only seems to happen during requests that only read data
>

I don't use ZODB, but I may have an idea on where to look / possible ways 
to create a repeatable test-case.

I think I've seen similar situations caused by transaction deadlocks or 
timeouts on readers high-concurrency situations when there is an extended 
write going on.  

for example, there are 50 connections reading and 1 connection writing. 
 sometimes the writer would grab a table/row lock for too long, which would 
cause a pileup of locks on the readers and a few would eventually fail. 
 under pyramid, the finished callbacks unconditionally fire after a request 
-- including timeouts and errors where there was never a properly setup 
transaction or database to cleanup.  So it would try to abort, but it never 
got started in the first place. 

this may be related to what you're experiencing.

-- 
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: Suggestion to store load data (non-db) as constants or in config on startup

[Jonathan Vanasco]

On Monday, April 11, 2016 at 5:23:26 PM UTC-4, Tres Seaver wrote:
>
> I do all such "global setup" tasks inside the "main" function, registered 
> as the 'paste.app_factory' entry point.  E.g.: 
>

I usually do the same, unless the "global setup" is happening in some sort 
of submodule/directory that already has a "def includeme(config)" that is 
scanned by the main function.  If that's the case, I'll keep the code 
organized there.

-- 
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:
>>
>> 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] correct way to close a sqlalchemy session?

[Jonathan Vanasco]

A few routes I have need to explicitly commit the session, and require me 
to use "long lasting sessions" 
(https://pypi.python.org/pypi/zope.sqlalchemy#long-lasting-session-scopes)

Since this disables transaction's call to "close" on commit, what is the 
best way to close the SqlAlchemy session?

I ended up using a Tween, but my first thought was to use 
"add_finished_callback" (but there was only a config object, not a request 
object).

-- 
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.

Re: [pylons-devel] weberror: Fix CSRF validation when token is unicode

[Jonathan Vanasco]

@Steve-

Would it make sense to just explicitly state "Pylons was put into 
maintenance-only status in 2012."  


On Tuesday, February 9, 2016 at 3:02:23 AM UTC-5, Steve Piercy wrote:
>
> I've also merged a PR to change the wording on this page to reflect 
> reality. 
> http://www.pylonsproject.org/projects/pylons-framework/about 
>
> Soon it will be deployed. 
>
> --steve 
>
>
> On 2/9/16 at 6:50 AM, hey...@gmail.com  (Jan Heylen) 
> pronounced: 
>
> > Great, thanks! 
> > 
> > On Tue, Feb 9, 2016 at 1:11 AM, Bert JW Regeer  > wrote: 
> > > I’ve just received push access to PyPi from Ben Bangert, will pull in 
> that PR 
> > and get a new release out that fixes the issue in the next day or so. 
> > > 
> > > Thanks, 
> > > Bert 
> > > 
> > >> On Feb 7, 2016, at 06:19, Jan Heylen > 
> wrote: 
> > >> 
> > >> Hi, 
> > >> 
> > >> as user of the pylons web framework, I very much like the interactive 
> > debugger, however, since some time, this is a broken feature. 
> > >> 
> > >> However, the fix (in weberror) is very trivial and already proposed 
> as pull 
> > request by Patrick Valsecchi on github since November last year: 
> > >> Https://github.com/pylons/weberror/pull/11 
> > >> 
> > >> I know Pylons is no longer actively maintained, but the website does 
> still 
> > states: "The Pylons web framework 1.x line will continue to be 
> maintained 
> > alongside Pyramid" :-) 
> > >> 
> > >> Will this pull request be taken in and will weberror be updated in 
> pypi? 
> > Currently, this is still a version without this fix. 
> > (https://pypi.python.org/pypi/WebError) 
> > >> 
> > >> Thanks, 
> > >> 
> > >> Jan Heylen 
> > >> 
> > >> 
> > >> 
> > >> 
> > >> 
> > >> -- 
> > >> 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...@googlegroups.com . 
> > >> To post to this group, send email to pylons...@googlegroups.com 
> . 
> > >> Visit this group at https://groups.google.com/group/pylons-devel. 
> > >> For more options, visit https://groups.google.com/d/optout. 
> > > 
> > > -- 
> > > 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...@googlegroups.com . 
> > > To post to this group, send email to pylons...@googlegroups.com 
> . 
> > > Visit this group at https://groups.google.com/group/pylons-devel. 
> > > For more options, visit https://groups.google.com/d/optout. 
> > 
>
>  
> Steve Piercy, Soquel, CA 
>
>

-- 
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.

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

[Jonathan Vanasco]

On Tuesday, January 5, 2016 at 2:06:28 AM UTC-5, Steve Piercy wrote:
>
> What is the value for maintaining the domain name pylonshq.com? 
>

permanent redirects for a few years for legacy links and search engines. 
that's about 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 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.

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

[Jonathan Vanasco]

On Wednesday, December 16, 2015 at 3:00:08 AM UTC-5, Robin Harms Oredsson 
wrote:
>
> OK thanks, I'll try to increase logging verbosity some way. The permission 
> part is something I've managed to rule out :/
>

Just to be sure... did you switch to the user that supervisor runs as, and 
were able to start it?  I know you wrote something above, but American 
english vs European english is a pain.

There is a supervisor mailing list too. It's not terribly high trafficked.  
https://lists.supervisord.org/mailman/listinfo/supervisor-users

-- 
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] Re: Deployment with supervisor + ZEO

[Jonathan Vanasco]

Then the only things I can think of are:

* user/permissions error on supervisor starting the process
* an environment variable missing/unset/overwritten in supervisor

-- 
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.

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

[Jonathan Vanasco]

If you're going to script a request, then you'll need to follow the 
bootstrap/commandline/shell docs.  That means loading your whole app and 
tying into the request lifecycle.  

I have some various commandline tasks that require me to run several tasks 
though a pyramid environment.

To handle those, I create a single environment via `bootstrap(ini_file)` 
and run a series of requests through it by using 
`pyramid.scripting.prepare_requst) to reset it each time.  something like 
that might help you, but you'll have to play around with specifics.

Generally speaking though, people want to use Celery to offload tasks -- 
not handle entire requests.

-- 
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.

[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: 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.

Re: [pylons-devel] ZODB News

[Jonathan Vanasco]

Most python software news is organized in planets.  There's a lots of ZODB 
over at http://planet.plone.org/


-- 
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] "Knob" for ACLAuthorizationPolicy?

[Jonathan Vanasco]

I may be reading this wrong, but couldn't you just define your custom 
attributes in `__customer_acl__` and `__api_acl__`, then define `__acl__` 
as a custom property on a shared base class that simply proxies the 
attributes in the lookup order you want over to Pyramid's default policy?

-- 
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: peewee ORM

[Jonathan Vanasco]

I'm not sure what `request.peewee_dbs()[db].connect()` does, but I would 
probably recommend against this db setup pattern that you're using.  By 
doing this in a tween, every request that pyramid handles will do a 
connect/disconnect to all the databases you defined.

One of the more popular patterns to implement db connections is something 
like this:

- `add_request_method` provides an object that either returns an database 
connection, or creates a new one.
- if you create a new connection, it registers a 'db.close()' via 
`add_finished_callback`

this way you only connect as needed, and disconnect to actually connected 
databases.

-- 
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] AuthTktAuthenticationPolicy's auth_tkt

[Jonathan Vanasco]

preface: I think you should be able to do what you want inside of Pyramid.

In terms of modifying a JSON response by ADDING an attribute (like the 
auth_id), it's not that hard and you don't need to deserialize.  You can 
capture the response in a tween and just replace the trailing '}' with ', 
"mykey": "myval"}'.  I've done this many times.  You only need to 
deserialize/re-encode if you're replacing or modifying an attribute.  If 
you're simply adding an attribute, then appending it on the end is all you 
need.

-- 
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] 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] Re: pcreate: Uppercase version of the package name?

[Jonathan Vanasco]

I would create an Issue and propose it on the Github.  One of the core 
maintainers will say something like "Great!", "Maybe..." or  "No way". 
 I've seen (and personally gotten) a lot more "No Way" than "Okay" for 
proposed changes.

This is such an edge case though, that I don't know if they'll go for it 
"as-is".  Why would other people need or use this?  I don't see it getting 
added unless you can come up with a compelling reason.

This is purely a guess - but I think you might have better luck proposing 
it as some sort of "hook" for pcreate.  i.e., if there was some way to pass 
in other template variables to pcreate.  


-- 
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 
``.  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.

Re: Newbie moving from Webapp2 to Pylons/Pyramids quick questions

[Jonathan Vanasco]

Wish I saw this earlier.

I use my own cookies and auth.  It was trivial to set up.

You can bootstrap any authorization/cookie setup with either an `event 
subscriber` ( NewRequest ) , a `tween` that wraps your app, or by setting 
up `class based View Callables` that inherit from a single base class ( 
which runs your setup in __init__ ).

The easiest ways I've found to handle locking down views are with 
decorators:

 @require_logged_in

-- 
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: is the current sqlalchemy scaffold 'correct' ?

[Jonathan Vanasco]

On Tuesday, July 23, 2013 2:52:32 AM UTC-4, Laurence Rowe wrote:
>
> I've not used the scaffold myself, but invalidation is handled by 
> zope.sqlalchemy which ties SQLAlchemy into Pyramid's request lifecycle with 
> pyramid_tm.
>

i didn't realize that pyramid_tm was in the environment.ini; thanks.
 

> I don't really understand the purpose of this recipe. 
>

the cookbook and mine do the same thing.  cookbook edits `config`, i used a 
tween.  it just stashes a new `db` session on the request object , and 
simultaneously registers a cleanup to roll it back.  if you're not using 
transaction, you need to do stuff like that. 

 

> I do prefer the ``session = DBSession()`` pattern myself. The SQLAlchemy 
> docs consistently refer to the scoped session factory as capitalized 
> ``Session`` and the thread local session as lowercased ``session``. I think 
> sticking fairly closely with the conventions from SQLAlchemy docs is 
> worthwhile so don't see the point in changing to ``local_session = 
> DBSessionFactory()``.  The Session -> DBSession naming is probably 
> worthwhile to avoid confusion with Pyramid's completely unrelated 
> request.session.
>

The SqlAlchemy docs and namespace are great for people who are coming to 
this from a Database perspective.  Many people won't both reading them 
until they're knee deep in playing with pyramid.  , and the `Session` vs 
`session` difference can be troubling.

People considering Pyramid over Django/Flask/etc can ( and do ) get 
confused with that completely unrelated request.session .

-- 
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.

Re: response callback and tween interaction

[Jonathan Vanasco]

this was super confusing to me for a while too, until i looked at some of 
my debug info and really understood the tweens.

iirc, the callstack is essentially:

* tween start
* `handler(request)` ( which can wrap other tweens )
* tween end
* response callback
* finished callback


the tweens are basically like python decorators or wsgi middleware .  even 
though they sound like a callback or some sort of "operation on a result", 
they're really just a logical block that wraps the action 
`handler(request)`.  

since your views are executed after all the tweens have begun , your 
callbacks haven't even been registered yet.


i may be in a similar situation as you -- i had some cleanup work being 
done in a tween , and it seemed to be creating some issues.

the idiom i've decided on now, is to do all my setup in the tween, but 
defer the cleanup to a finished_callback


it looks like this:

def my_tween_factory(handler,registry):
def my_tween(request):
try:
request.add_finished_callback(my_cleanup)
my_setup(request)
response = handler(request)
return response
finally :
log.debug('ok')
 return my_tween


-- 
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:
http://example.com"; data-a="1" data-b-a="2">Link to 
Example.com

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.

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: question about design decision on pyramid's core

[Jonathan Vanasco]

On Mar 27, 4:33 pm, Blaise Laflamme  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.

optimizing whitespace in mako templates

[Jonathan Vanasco]

I've been working on a method to optimize whitespace with Mako
templates -- instead of collapsing insignificant whitespace after
Pyramid renders the view_callable, it's stripped when Mako first
compiles the template.

I'm trying to figure out the best way to integrate this with Pyramid.

At first I was going to pass in a single config argument, but then I
realized that this needed to have some sort of conditional control on
this -- for those cases when rendering plaintext email or other types
of files where all whitespace is significant.

When I started going through the `pyramid/mako_templating.py` file , i
saw that the lookup ( line 154 ) was tied down to a subset of the
kwargs allowed by mako.lookup.TemplateLookup.__init__ ( line 147 ).
Only about half of the arguments are allows.

I was thinking about different ways to enable a passthrough of all
mako arguments, and this came to mind:

add to pyramid/config/settings.py :

class SettingsSection(Settings):
def __init__(self, settings=None, section_prefix=None, **kw):
if settings is None:
settings = {}
section_prefix_len = len(section_prefix)
section = dict([  (k[section_prefix_len:],v) for k,v in
settings.items() if k[:section_prefix_len] == section_prefix ])
for (k,v) in kw.items():
if k not in section:
 section[k] = v
dict.__init__(self, **section)

then grabbing the entire mako section , with defaults , would be
something like:

mako_defaults = {\
'directories' : [],
'module_directory' : None,
'input_encoding':'utf-8'  ,
'error_handler':None,
...
}
mako_settings = SettingsSection( settings , 'mako.' ,
**mako_defaults )

i mocked up a gist here:  https://gist.github.com/jvanasco/5257232

it's not a perfect solution , as a handful of current settings need to
have pyramid operate on them ( such as the dotted name resolver. )
But something like this could allow for more mako arguments to be
passed it, without requiring a user to completely reimplement the
mako_templating infrastructure.

The only other idea I had, was to allow a user-defined mako lookup
routine to be configured.  That seemed more extensible, but messier.

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?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.

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: 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 9, 2:21 pm, Blaise Laflamme  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.

Re: how are the pyramid docs managed ?

[Jonathan Vanasco]

On Feb 8, 3:46 pm, Blaise Laflamme  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 

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.

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.

Re: Suggestion for Request namespace provisioning

[Jonathan Vanasco]

these are all good points.

-- 
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/-/XOhPX89JubgJ.
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.

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: OAuth 2.0 for Pyramid

[Jonathan Vanasco]

holy crap that sounds awesome.


On Tuesday, September 25, 2012 2:42:24 PM UTC-4, Michael Merickel wrote:
>
> On Tue, Sep 25, 2012 at 1:13 PM, Jonathan Vanasco 
> > 
> wrote: 
> > This is purely my very opinionated 2¢ ... 
> > 
> > I've had to integrate against oAuth a few times, and have constantly 
> found 
> > it a hassle. 
> > 
> > The existing 'core' Python libraries for it are rather scattered in 
> terms of 
> > active development, maturity and "street cred" ( by which I mean that 
> > you'll often find a big name website saying "You should use this library 
> for 
> > oAuth against our API!", yet that library is badly documented, barely 
> > functional, often really out of date with current specs , and ships with 
> a 
> > bunch of its own tests which it won't even pass ). 
>
> I believe this is the purpose of oauthlib. I'd love to see a reference 
> implementation in pyramid. 
>
> https://github.com/idan/oauthlib 
>

-- 
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/-/Q4E1W6dx7qkJ.
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: OAuth 2.0 for Pyramid

[Jonathan Vanasco]

This is purely my very opinionated 2¢ ...

I've had to integrate against oAuth a few times, and have constantly found 
it a hassle.

The existing 'core' Python libraries for it are rather scattered in terms 
of active development, maturity and "street cred" ( by which I mean that 
 you'll often find a big name website saying "You should use this library 
for oAuth against our API!", yet that library is badly documented, barely 
functional, often really out of date with current specs , and ships with a 
bunch of its own tests which it won't even pass ).

I've seen a handful of oAuth plugins and "micro-frameworks" for django or 
uwsgi servers too.  They try to be a complete plug&play solution, but then 
you have to worry about integrating the endpoints, skinning the views, and 
persisting the data.  After a few minutes of playing with the modules -- if 
your app doesn't meet the exact specs/design requirements of these plugins, 
you're looking at a huge mess and really unattractive option.

So for general feedback, I would suggest this:

1- make a core oAuth library that just works , is up to date , and is 
designed to easily integrate against
2- create a reference Pyramid/etc implementation of the client and server 
functions ( ie, like your sample views )
3- create a bunch of helper functions that aid in setting up the above , 
which people can just call if they're lazy.  

Using SqlAlchemy as a datastore is a neat feature , but there are 2 red 
flags to me:

- it doesn't look like i'll ( easily or at all ) be able to override your 
tablesnames or database structure 
- i'm now limited to sqlalchemy supported databases.  if i'm on 
mysql/postgresql/oracle, that's fine - but if i'm using a mongodb or 
similar datastore -- forget it.

I would, personally, prefer to have some sort of "config" object that I can 
pass in - which defines/provides some callbacks for searching and storing 
data.  

Having a drop-in capability and default settings of sqlalchemy are both 
fine –- but relying on it?  that seems too much like rails/django and all 
that standardization/configuration restrictions which are a huge part of 
the reason why people choose Pyramid , Flask, or other frameworks instead 
of Django.


-- 
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/-/n7cYxSmYBzsJ.
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.

Re: Documentation Suggestions for Subscribers or Debug

[Jonathan Vanasco]

On May 15, 7:33 pm, Michael Merickel  wrote:
> What? Pyramid doesn't have a "debug" code path, minus emitting some
> log messages. Do you mean that the debugtoolbar is doing something to
> the response?

I'd imagine its either the error screens from pyramid_debugtoolbar or
whatever settings like debug_templates control.

pyramid.debug_templates = true
pyramid.includes = pyramid_debugtoolbar

when they're enabled, they seem to hijack the response object and
replease it with their own -- it no longer contains any trace of the
raised exception (unless you regex the debug screen html)

-- 
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]

glad to help!

On Mar 13, 10:43 pm, Massimo DiPierro 
wrote:
> I just did it.
>
> http://pypi.python.org/pypi/Gluino
>
> Thanks for the help.
>
> massimo
>
> On Mar 13, 2012, at 9:36 PM, Jonathan Vanasco wrote:
>
>
>
>
>
>
>
> > 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 
> > athttp://groups.google.com/group/pylons-devel?hl=en.

-- 
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.

any plans for a pyramid category in python ?

[Jonathan Vanasco]

the current classifier is :

Framework :: Pylons

that makes sense for Pylons stuff, but Pyramid is a bit of a
departure.  i.e. things labeled "Framework :: Pylons" but intended for
Pyramid are likely to not work under Pylons at all.

-- 
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: pyramid should explicitly require pastescript

[Jonathan Vanasco]

i'm not too familiar with "paster create" - do you think it would be
possible to make an entry point that warned people to use pcreate?

-- 
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: pyramid should explicitly require pastescript

[Jonathan Vanasco]

and playing around a bit, i see that the newest version of pyramid
moved to pcreate from paster create... so perhaps the above is not
needed.

-- 
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.

pyramid should explicitly require pastescript

[Jonathan Vanasco]

I think at one point it was required by one of pyramids dependents,
and then it changed.

It's either not possible or safe to create a new project with paster
right now.

For example:

- On my OSX 10.6 machine , I used to run pylons under 2.6.
- I upgraded python to 2.7 to build & migrate some apps to pyramid.
The Python.org 2.7 mac installer leaves 2.6 intact, installs 2.7 into
a new directory structure, and adjusts environment variables to give
it precedence.
- I noticed during a recent traceback, that paster wasn't being called
from my projects virtualenv ( which is built against the new 2.7
install ) -- but instead from the original 2.6 install.
- a simple `pip_install pastescript` has everything running correctly
now

i literally caught the 2.6 out of the corner of my eye.  i'm guessing
few seasoned people would run into this, because they have paster
somewhere on their system already.

-- 
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: Some thoughts about Pyramid

[Jonathan Vanasco]

I think the criticisms in the post -- and their defense here -- are
really important.  I've had the same struggles.

While many are not technically valid , they appear to be so because of
the documentation and positioning of pyramid.

Pyramid is really powerful framework, but its also quite low-level.
Most frameworks are high-level.  While this can be very powerful, it
can also be frustrating.

As an example, look at the concept of Auth -- the pyramid auth system
is ( unless there are new magical docs out there ) very much
positioned at doing some fine-grained authentication ( users, groups,
actions) based on each 'view'.  Most other frameworks use advanced
plugins for this sort of functionality... and have much simpler
plugins to handle authentication for each handler / controller / etc
as a package.  ie: for the majority of web applications, the state of
being "logged in" is the only requirement for access to every method
of a class/package, and having to (re)declare auth policies per method
becomes daunting.

I mentioned "unless there are new magical docs", because I think 99%
of the problems with pyramid right now are the docs.  They're hard to
sift through (rather dense) and easy to miss things in.  Meanwhile,
docs for projects like Django and Rails are really light and breezy...
and link to the more-in-depth specialized docs and api docs.

-- 
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: create_slug helper

[Jonathan Vanasco]

oh neat!

at first i thought this was for some sort of preview text, then
realized it was for a url friendly marker

i do something a little different.

also, i'd check to make sure what you get the url chars from. last i
checked, most things in python, perl, etc were written to rfc 1738 or
2396 but rfc 3986 was the current.

anyways, i have a url encoding module as such:

   http://paste.pocoo.org/show/QOLc8c6FD7Mqvyu28lSg/

which references some functions in a Misc package

   http://paste.pocoo.org/show/123669/

then i call it through:

   ( standardized, stripped, metaphoned ) = string_to_webtitle_data
( string )

which gives me the slug, a nice text display version, and a metaphone
encoding.

it's less useful for social-bookmarking and more useful for creating
'dictionary' or 'phonebook' style directories


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

validators idea

[Jonathan Vanasco]

how would people feel about having a config option to replace the
c.form_errors object in pylons/validators/__init__.py with an
AttribSafeContextObject from pylons/util.py -- the same sort of object
that c is

i'd be glad to patch it if people agree -- a lot of my templates would
look way cleaner with that sort of functionality


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

helpers function submission - url_is_valid

[Jonathan Vanasco]

only works with routes, but i didn't find any non-routes mappers for
pylons ;)

this is a dumb little helper that is useful as all hell (though it
took me too long tracing vars throughout pylons to figure out )

personally, i think url_for should call this as well, to make sure
that it generates valid routes ( as url_for('/my/invalid_path') will
return '/my/invalid/path' and does no checking )

---

def url_is_valid(path):
map = config['routes.map']
matches = map.match(path)
if matches:
return True
return False


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---