On Jul 16, 2007, at 1:50 PM, Chris Perkins wrote:
> > On Jul 16, 1:47 pm, Philip Jenvey <[EMAIL PROTECTED]> wrote: >> On Jul 15, 2007, at 2:26 PM, Chris Perkins wrote: >>> On Jul 15, 4:57 pm, Ben Bangert <[EMAIL PROTECTED]> wrote: >> >>>> This is a strange issue that appears to happen on windows, go into >>>> the projects dir and run: >>>> python setup.py egg_info >> >>>> And you should be fine. >> >>> OK, thanks. After doing that I get a different traceback when I do >>> "paster serve": >> >>> File "i:\python25\lib\site-packages\pastedeploy-1.3-py2.5.egg >>> \paste >>> \deploy\util\fixtypeerror.py", line 57, in fix_call >>> val = callable(*args, **kw) >>> File "wln\config\middleware.py", line 33, in make_app >>> load_environment(global_conf, app_conf) >>> File "wln\config\environment.py", line 20, in load_environment >>> config.init_app(global_conf, app_conf, package='wln', >>> AttributeError: 'module' object has no attribute 'init_app' >> >>> Any more tips? >> >> What does your environment.py look like? >> >> What version of Python are you using (2.5 or 2.5.1)? > > Python version is 2.5.1. > >> From memory (I'm at work, and the problem is on my home computer), my > environment.py contains: > > from pylons import config, near the top, and > config.init_app(...), later (as you can see in the traceback I > posted). > > It seems to me like the pylons template does not match up with the > pylons code. The pylons.config module indeed does not contain an > init_app function, but it does contain a Config class that contains an > init_app method. Perhaps the template was updated too soon to use a > new (not yet released) version of pylons.config? > It's more complicated than that. In 0.9.5, pylons.config was a module, but we wanted to use pylons.config as an object in 0.9.6. We also wanted to support the old syntax used in 0.9.5 projects for backwards compatibility: import pylons.config This line of code doesn't work unless pylons.config is an actual module. To do this we have a gross little hack -- we maintain the pylons.config module, however when importing it (really the pylons package), the pylons/__init__.py sets its config variable to our new object, which overwrites the module. Note this little hack is temporary, it will have as short of a lifetime as possible (one or two Pylons versions) -- it's just to give folks time to migrate to the new style. It seems to work fine, but for some reason it's not working on your environment -- you end up with a module at pylons.config, not our new 0.9.6 object. This worries me, but oddly enough I'm unable to reproduce it, even on a similar environment to yours (Windows XP, Python 2.5.1). I tried both a new project and an older style project. Is there anything special about your environment? Maybe your project is actually using the Pylons 0.9.5 codebase for some reason? -- Philip Jenvey --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
