SQLAlchemy in the QuickWiki tutorial
Hey guys, I'd like to update http://pylonshq.com/project/pylonshq/wiki/SqlAlchemyWithPylons based on the new features in Pylons 0.9.4.1. I see that the QuickWiki tutorial is still using DynamicMetaData() instead of reflecting the data from the database. In my app, I need to reflect the data. To do this, I need to actually connect to the database. To connect, I need access to the dburi. I wanted to see if the session_context now had access to the dburi when model/__init__.py is being loaded. Hence, I threw in the following at the top of the file: from pylons.database import session_context import pdb pdb.set_trace() Then, in pdb: (Pdb) session_context.get_current() *** TypeError: No configuration has been registered for this process or thread Am I correct in inferring that it's still not possible to reflect the schema using the way the Quick Wiki tutorial sets things up? Thanks, -jj -- http://jjinux.blogspot.com/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@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-discuss?hl=en -~--~~~~--~~--~--~---
more complicated deployment configuration?
Hi everyone, We're bumping into a problem with our deployment configuration. We'd like to do a little more sophisticated configuration, but can't figure out how to do it. Specifically, it seems like we need at least one level of nesting (we'd like to declare some entities and then specify some properties for them). Unfortunately, I can't seem to figure out how to do this inside a deployment configuration. It seems like I'm supposed to put everything inside [app:main] -- and .ini files only seem to support that one level of nesting. I wouldn't mind having an option that pointed to a separate config file in the same directory (as the deployment config file), but I can't figure out how to figure out which deployment config file was used either. I noticed LilPlanet lists all the feeds inside one giant string and then does a string split. Seems like there might be a better solution out there. Anyone else bump in to something like this? And if so, how'd you solve it? Toph --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@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-discuss?hl=en -~--~~~~--~~--~--~---
Re: ANN: AuthKit 0.3.0pre4
On Fri, 2007-02-16 at 15:02 +, James Gardner wrote: I'd encourage anyone who is currently using the dev version to upgrade to 0.3.0pre4 so we can see if there are any issues before 0.3.0 is formally released in a couple of weeks time. It fails for me with: AuthKit-0.3.0pre4-py2.4.egg/authkit/authenticate/__init__.py, line 125, in _get_value raise AuthKitConfigError( authkit.authenticate.AuthKitConfigError: The required option 'authkit.method' was not specified However I do have authkit.method = forward in my .ini file (and this worked with the prior release). Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@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-discuss?hl=en -~--~~~~--~~--~--~---
Re: Fast Python webserver
Ian Bicking wrote: Cliff Wells wrote: I'll probably do some better tests later, but my initial suspicion is that the default paster serve isn't as fast as CherryPy (both are proxyied to via Nginx). In my simplistic tests CherryPy 3 is about 50% faster than paste.httpserver. That's keeping everything else equivalent, and not including any framework. I don't know how other factors would effect that. I'm going to be doing some performance tests on my setup in the next few days, but one thing I've noticed in preliminary playing is that using fastcgi/flup with nginx is noticeably faster than a straight proxy. Pylons has some performance gotchas if you use threadlocals in certain ways. Care to elaborate? Robert --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@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-discuss?hl=en -~--~~~~--~~--~--~---
Re: Fast Python webserver
Robert Leftwich wrote: Ian Bicking wrote: Cliff Wells wrote: I'll probably do some better tests later, but my initial suspicion is that the default paster serve isn't as fast as CherryPy (both are proxyied to via Nginx). In my simplistic tests CherryPy 3 is about 50% faster than paste.httpserver. That's keeping everything else equivalent, and not including any framework. I don't know how other factors would effect that. I'm going to be doing some performance tests on my setup in the next few days, but one thing I've noticed in preliminary playing is that using fastcgi/flup with nginx is noticeably faster than a straight proxy. FastCGI doesn't seem substantially easier to parse than HTTP, so I'm not sure why that'd be. Maybe flup is just faster than paste.httpserver. Or maybe there's something different about the way connections are handled (are FastCGI connections persistent in any way?). Pylons has some performance gotchas if you use threadlocals in certain ways. Care to elaborate? Everytime you access an attribute on c or g (or pylons.request/response) there is a threadlocal lookup which adds some overhead. If you do it in a loop (e.g., for c.name in big_list) it can become a big hit. If you have just a handful of such lookups it's not a big deal. -- Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@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-discuss?hl=en -~--~~~~--~~--~--~---
Re: Fast Python webserver
Ian Bicking wrote: (are FastCGI connections persistent in any way?). Not that I'm aware of. Hopefully, I'll have some more definitive numbers in a few days. Robert --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@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-discuss?hl=en -~--~~~~--~~--~--~---
Upgrading Pylons dependencies
Hi all, I was at a client's yesterday, installing a dev environment for them, and was hit by one annoying easy_install upgrade limitation: Before going on site, I upgraded my local Pylons to latest using easy_install -U Pylons (which upgraded Pylons and Routes), to make sure the app still works. Surely enough, once at the client's, installed everything and... the app did not work (^_^;). Took a quick look at it, and I noticed some version differences. That's when I realized that my local easy_install -U Pylons upgraded Routes (probably because of a new version requirement), but left the other packages alone (I am guessing: current version requirement satisfied). Googling for this a bit, I found this: http://mail.python.org/pipermail/distutils-sig/2006-April/006210.html which confirms that easy_install -U does not upgrade dependencies. Now that I think of it in terms of version requirements, it totally makes sense, but FWIW, my initial feeling was: doing easy_install -U Pylons should give me the same environment (by that I mean: Pylons and its dependencies) as doing easy_install Pylons on a fresh machine. In light of this, the install documentation (http://pylonshq.com/docs/ 0.9.4.1/install.html) is a bit misleading, as it just tells you to run easy_install -U Pylons to upgrade. Maybe a short note below this would help preventing others from making the same mistake. Something along the lines of: Note that Pylons dependencies will only be upgraded if necessary. There may be newer versions available, that you would get doing a fresh install, but these will *not* be upgraded if the current version requirements are satisfied. Cheers, -- Yves-Eric --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@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-discuss?hl=en -~--~~~~--~~--~--~---
Re: pylons, genshi and xml
On Tue, 2007-02-13 at 17:00 -0800, Ben Bangert wrote: On Feb 13, 2007, at 2:11 PM, Matt Good wrote: Yes, this was based on the Kid engine provided by TurboGears which uses module-style names to load templates. Last I checked Pylons also expected all template engines besides Myghty and Mako to use this convention. I plan to make the Genshi plugin usable with file paths as well, but of course I need to be sure to allow for backwards compatibility. In the Mako plugin, I've set it up so that if you have a / in the template name, it assumes you're doing full paths. Thus if it sees 'dir.tmpl' it assumes its dot notation template, and if its '/dir/ tmpl.html' it assumes its a path due to the /. If the Genshi template does this toggling as well, I'll add Genshi to the template engines that don't have their path 'touched' before it goes to the template engine. I'm not thrilled to be hacking around the TG spec, clearly a new spec is needed but as there doesn't seem to be any traction or clear leader of that spec and its evolution this should work decently in the meantime. Actually, the TG spec is completely superfluous. You can use / rather than . and it will work just fine. I just removed support for dotted path notation from Breve as it causes problems (e.g. paths with dots in them) and provides nothing in return. If you don't have a large userbase of people expecting dot notation to work, I'd get rid of it now before you do. Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@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-discuss?hl=en -~--~~~~--~~--~--~---
