Pylons 0.9.6 Release Candidate 1
Ben Bangert
We're putting out a release candidate for 0.9.6 this time to ensure
any quirks we find can be corrected before the final. Please feel
free to update your projects (http://wiki.pylonshq.com/display/
pylonsdocs/Upgrading), of course keep a backup of your existing one. :)
After we're sure the release candidate is solid, we'll release the
official 0.9.6.
I'd like to thank Phil Jenvey and the many other contributers who've
helped make 0.9.6 a great update. David Smith is also now a core
Pylons committer and we're looking forward to his help with the project.
There's some very important changes in this release as we further
deprecate some things that will eventually be going away. All major
changes that you should watch for in your project are in the
changelog with a big WARNING.
The big changes summarized:
- Global response object
Back in 0.8, there was a global response object as well, which went
away in favor of explicitly returning a Response object. However
after much discussion with other Pylons users, the incredible
usefulness of a global response object made it too tough to pass by.
Bringing a global response object into the system also made a lot of
tasks significantly simpler.
- pylons.database is deprecated, its not going away quite yet, but we
*highly* encourage everyone to start using SAContext. It works great,
and really makes things easy.
- Global config object
People have been trying to get to their config options from a
variety of places, and there just wasn't a consistent and easy way to
do it. Now there is, with the pylons.config object. This change also
streamlines the environment.py and middleware.py files in your
project, so that middleware is *just* middleware, and the environent
file sets up all your project options.
There's a ton of other fixes as well, please submit any bugs
discovered, hopefully we won't need a release candidate 2. :)
Cheers,
Ben Bangert
The CHANGELOG:
* Fixed cookie header addition to use add instead of append. Thanks to
anonymous patcher. Fixes #268, again.
* Added ability to pass _code option to specify the status code type for
redirect_to.
* Fixed redirect_to to not copy all headers into redirect for old
_response
usage. Fixes #268.
* WARNING: By default, the Pylons response object now returns unicode
parameter (pylons.GET/POST/params) values (and assumes those
parameters
were sent to Pylons as utf-8). Unicode parameters can cause major
problems if your application is not setup to handle unicode. To
disable
unicode parameters (0.9.5 default behavior), add the following to
your
load_environment function (0.9.6 syntax):
pylons.config['request_options']['charset'] = None
or, if still using the deprecated pre-0.9.6 pylons.config syntax,
add:
request_settings = pylons.config.request_defaults.copy()
request_settings['charset'] = None
return pylons.config.Config(tmpl_options, map, paths,
request_settings=request_settings)
* WARNING: Template names beginning with a / (or the OS's path
separator)
will now result in the name not having the separator's replaced
with '.'s
for the template engine. This shouldn't affect most projects as
they usually
assume a dot notation will be used with dot notation template
engines (Kid,
Genshi, etc.). This change allows template engines that can take
filename
paths to function properly. Fixes #233.
* WARNING: The pylons.util.get_prefix(environ) function is
deprecated. Please
use:
environ.get('SCRIPT_NAME', '')
instead (the get_prefix function is used in the default
ErrorController).
Fixes #243.
* WARNING: The paths dictionary's 'root_path' has moved to the less
redundant 'root'.
* Fixed the Error Documents/EvalException css referencing non-
existent images.
Thanks Shannon -jj Behrens. Fixes #238.
* Added ability to pass _code option to specify the status code type for
redirect_to.
* Fixed redirect_to to not copy all headers into redirect for old
_response
usage. Fixes #268.
* Added logging statements throughout Pylons code, added logging
setup to
default template. Fixes #98.
* Refactored global response to be setup in wsgiapp along with the other
globals. Updated WSGIController to copy in global response headers
and
cookies into a WSGI app's output.
* Added global pylons.response object. Thanks Shannon -jj Behrens and
Damjan
Georgievski. Fixes #268 and #201.
* Updated default project template files for new configuration
layout. Options
to handle config now just in environment.py, and middleware.py
handling just
middleware. Fixes #203.
* Removing mako tests, as its now the default. Default test changed from
Myghty to Mako.
* Changing default templating to mako.
* Added the https decorator. It requires an action to be loaded via
https. Patch by ido. Fixes #241.
* Added upgrade instructions, and posted a copy on the wiki. Fixes #230.
* Added deprecation warnings for usage of the Pylons Controller
class, all
controllers should inherit from WSGIController instead. Fixes #239.
* Removed deprecated attach_locals function from Controller class.
* Added an authenticate_form decorator for use with WebHelpers'
secure_form_tag functions for preventing CSRF attacks. Original patch
by David Turner. Fixes #157.
* Fix Buffet's include_pylons_variables not being upheld. Thanks
Jonathan
LaCour.
* The validate decorator now accepts extra keyword arguments
(**htmlfill_kwargs)
to pass along to formencode's htmlfill.render function.
* Removed POST-only restriction on validate decorator, now handles GET
requests. No form arg required during a GET request, which will
run the
current action with c.form_errors set to the errors. Fixes #246.
* Added PylonsConfig, which gets accessed as pylons.config dict.
Contains
all the merged ini options, in addition to the Config options such as
'routes.map', 'pylons.paths', 'buffet.template_options', etc.
Check the
pylons.config docs on PylonsConfig for dict keys populated by it.
* Split up resolution stages in wsgiapp, so that controller lookup is a
separate function making it easier to subclass. PylonsApp now takes a
base_wsgi_app argument which is then used for the BaseWSGIApp
instead of the
one from wsgiapp.py.
* Added mako template render tests.
* Added storage of the action func used to handle a call, for later
code that
might need a reference to the action that originally handled the
request.
Fixes #253.
* Updated config object to optionally take a single merged conf dict,
updated
project templates to pass around the single merged conf dict.
* Changed project template to use new Beaker session keys.
* Changed default routing for raw template matching to not unicode
decode the
route argument. Fixes #242.
* Catch any exceptions raised by template engine entry points and emit a
warning instead of crashing. Thanks markbradley. Fixes #249
* Fixed the validate decorator not working with formencode's
CompoundValidators when variable_decode=False. Fixes #209.
* Fixed the validate decorator failing with a KeyError when no value is
specified to validate against for separate validators (as opposed
to a
schema). Reported by Graham Stratton.
* Fixed paster shell not merging app_conf and global_conf into the
main CONFIG
dict namespace. Original patch by David Smith. Fixes #244.
* Added logging to decorators. Refs #98.
* Fixed paster restcontroller to test for lib.base and only add that
import
statement when its present. This fixes the restcontroller template
when used
with minimal Pylons project templates. Fixes #237.
* Fixed the EvalException debugger showing broken links and buttons
when the
app's ErrorController was broken (such as when BaseController's
__before__
raises an exception). Suggested by Ian Bicking. Fixes #228.
* paster create now accepts a 'template_engine' option to setup the new
project's default template engine. E.g. to create a new project that
uses Genshi by default, use:
paster create --template=pylons mygenshiproj template_engine=genshi
Suggested by Ian Bicking. Fixes #141.
* Fixed the validate decorator triggering the following error with
FormEncode>=0.7 and non-ascii rendered form content:
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in
position 10:
ordinal not in range(128) the form was passed in as an encoded
string, but
some data or error messages were unicode strings; the form should
be passed
in as a unicode string
Reported by Christoph Haas.
* HTTPExceptions are now converted to Response objects (for __after__),
making the httpexceptions middleware no longer required.
* Added Warning to jsonify to warn about cross-site attacks when
returning
a list as the outer-most element to jsonify. Fixes #232.
* Fixed beaker_cache decorator to take optional keyword arguments
intended
for the backend cache container (such as url for memcached).
* Fixed paster controller assuming the minimal template was in use when
the lib.base module existed but raised an exception.
* Fixed bug in XMLRPC Controller not setting proper Content-Type.
Fixes #236.
* Added the '-d' ('--disable-ipython') option to paster shell for
disabling IPython.
* Allow creation of controllers named 'setup' via paster controller.
Reported by Matt Good.
* Added support for generic arguments to SQLAlchemy's create_engine of
the form sqlalchemy.* from the PasteDeploy config file.
voltron
Great to see that a new shiny Pylons version is out :-)) I upgraded
Pylons to 0.96 RC1 with "easy_install -U Pylons". To test, I just
created a new app with "paster create -t pylons test3". Instad of a
working test I got these errors when starting the new app:
D:\Projects\Pylons_projects\test3>paster serve --reload
development.ini
Starting subprocess with file monitor
Traceback (most recent call last):
File "C:\Python24\Scripts\paster-script.py", line 7, in ?
sys.exit(
File "c:\python24\lib\site-packages\PasteScript-1.3.4-py2.4.egg\paste
\script\c
ommand.py", line 76, in run
invoke(command, command_name, options, args[1:])
File "c:\python24\lib\site-packages\PasteScript-1.3.4-py2.4.egg\paste
\script\c
ommand.py", line 115, in invoke
exit_code = runner.run(args)
File "c:\python24\lib\site-packages\PasteScript-1.3.4-py2.4.egg\paste
\script\c
ommand.py", line 210, in run
result = self.command()
File "c:\python24\lib\site-packages\PasteScript-1.3.4-py2.4.egg\paste
\script\s
erve.py", line 219, in command
relative_to=base, global_conf=vars)
File "c:\python24\lib\site-packages\PasteScript-1.3.4-py2.4.egg\paste
\script\s
erve.py", line 251, in loadapp
return loadapp(
File "c:\python24\lib\site-packages\PasteDeploy-1.3-py2.4.egg\paste
\deploy\loa
dwsgi.py", line 193, in loadapp
return loadobj(APP, uri, name=name, **kw)
File "c:\python24\lib\site-packages\PasteDeploy-1.3-py2.4.egg\paste
\deploy\loa
dwsgi.py", line 213, in loadobj
global_conf=global_conf)
File "c:\python24\lib\site-packages\PasteDeploy-1.3-py2.4.egg\paste
\deploy\loa
dwsgi.py", line 237, in loadcontext
global_conf=global_conf)
File "c:\python24\lib\site-packages\PasteDeploy-1.3-py2.4.egg\paste
\deploy\loa
dwsgi.py", line 267, in _loadconfig
return loader.get_context(object_type, name, global_conf)
File "c:\python24\lib\site-packages\PasteDeploy-1.3-py2.4.egg\paste
\deploy\loa
dwsgi.py", line 393, in get_context
section)
File "c:\python24\lib\site-packages\PasteDeploy-1.3-py2.4.egg\paste
\deploy\loa
dwsgi.py", line 414, in _context_from_use
context = self.get_context(
File "c:\python24\lib\site-packages\PasteDeploy-1.3-py2.4.egg\paste
\deploy\loa
dwsgi.py", line 345, in get_context
global_conf=global_conf)
File "c:\python24\lib\site-packages\PasteDeploy-1.3-py2.4.egg\paste
\deploy\loa
dwsgi.py", line 237, in loadcontext
global_conf=global_conf)
File "c:\python24\lib\site-packages\PasteDeploy-1.3-py2.4.egg\paste
\deploy\loa
dwsgi.py", line 274, in _loadegg
return loader.get_context(object_type, name, global_conf)
File "c:\python24\lib\site-packages\PasteDeploy-1.3-py2.4.egg\paste
\deploy\loa
dwsgi.py", line 541, in get_context
entry_point, protocol, ep_name = self.find_egg_entry_point(
File "c:\python24\lib\site-packages\PasteDeploy-1.3-py2.4.egg\paste
\deploy\loa
dwsgi.py", line 573, in find_egg_entry_point
raise LookupError(
LookupError: Entry point 'main' not found in egg 'test3' (dir: d:
\projects\pylon
s_projects\test3; protocols: paste.app_factory,
paste.composite_factory, paste.c
omposit_factory; entry_points: )
Is there something that I have skipped?
Thanks
Ben Bangert
> Great to see that a new shiny Pylons version is out :-)) I upgraded
> Pylons to 0.96 RC1 with "easy_install -U Pylons". To test, I just
> created a new app with "paster create -t pylons test3". Instad of a
> working test I got these errors when starting the new app:
>
> File "c:\python24\lib\site-packages\PasteDeploy-1.3-py2.4.egg\paste
> \deploy\loa
> dwsgi.py", line 541, in get_context
> entry_point, protocol, ep_name = self.find_egg_entry_point(
> File "c:\python24\lib\site-packages\PasteDeploy-1.3-py2.4.egg\paste
> \deploy\loa
> dwsgi.py", line 573, in find_egg_entry_point
> raise LookupError(
> LookupError: Entry point 'main' not found in egg 'test3' (dir: d:
> \projects\pylon
> s_projects\test3; protocols: paste.app_factory,
> paste.composite_factory, paste.c
> omposit_factory; entry_points: )
>
> Is there something that I have skipped?
Sounds like paster on your machine didn't setup the project to be
scanned for entrypoints. Try running:
python setup.py egg_info
Inside the project, it should run then (this step doesn't seem
necessary on *nix machines though).
Cheers,
Ben
voltron
That worked, the project starts now. Is there some documentation
somewhere that I can read about how things are to done with this new
version? For example:
1. Using SAContext with 0.96
2. using the Global config object
3. Using the Global response object
4. How to use HTTPExceptions in a controller
Thanks!
> smime.p7s
> 3KDownload
Ben Bangert
> That worked, the project starts now. Is there some documentation
> somewhere that I can read about how things are to done with this new
> version? For example:
>
> 1. Using SAContext with 0.96
The latest SAContext works fine, and I believe 0.2.1 also worked ok.
> 2. using the Global config object
Instead of looking for app_config['something'], or using the CONFIG
['somekey'] from paste.deploy, you can just use:
from pylons import config
sadburi = config['sqlalchemy.dburi']
This works whether your application is answering a response, and it
works as soon as you load your WSGI app (ie, in a shell script). So
your config info is in the same place in either case (it wasn't
before 0.9.6).
> 3. Using the Global response object
There's now a pylons.response global object. Just add headers or
cookies, or change the content type of it, and have your controller
return a string. So instead of:
return render_response('/some/template.html')
It's just:
return render('/some/template.html')
The headers and cookies from the global response object will be sent
out. This means you can also write functions elsewhere that use the
response global to set headers and they'll *just work*, rather than
having to try and pass the Response object around to add things to
the response.
> 4. How to use HTTPExceptions in a controller
Same as before, just abort(404) or how you were doing it before. If
its a 3XX status code, cookies will still be retained from the global
response object as well.
Cheers,
Ben
Jose Galvez
Ben Bangert wrote:
> On Jul 15, 2007, at 10:25 AM, voltron wrote:
>
>> That worked, the project starts now. Is there some documentation
>> somewhere that I can read about how things are to done with this new
>> version? For example:
>>
>> 1. Using SAContext with 0.96
>
> The latest SAContext works fine, and I believe 0.2.1 also worked ok.
>
>> 2. using the Global config object
>
> Instead of looking for app_config['something'], or using the
> CONFIG['somekey'] from paste.deploy, you can just use:
> from pylons import config
>
> sadburi = config['sqlalchemy.dburi']
>
> This works whether your application is answering a response, and it
> works as soon as you load your WSGI app (ie, in a shell script). So
> your config info is in the same place in either case (it wasn't before
> 0.9.6).
>
>> 3. Using the Global response object
>
> There's now a pylons.response global object. Just add headers or
> cookies, or change the content type of it, and have your controller
> return a string. So instead of:
> return render_response('/some/template.html')
>
> It's just:
> return render('/some/template.html')
wow this looks like a big change where can I do some reading up on it
and how to use it?, how exactly would we change the content-type or add
a cookie? if its global wouldn't changing the content type or adding a
cookie effect all your controllers and actions rather then just the one
your working on?
>
> The headers and cookies from the global response object will be sent
> out. This means you can also write functions elsewhere that use the
> response global to set headers and they'll *just work*, rather than
> having to try and pass the Response object around to add things to the
> response.
>
>> 4. How to use HTTPExceptions in a controller
>
> Same as before, just abort(404) or how you were doing it before. If
> its a 3XX status code, cookies will still be retained from the global
> response object as well.
>
> Cheers,
> Ben
Thanks for the hard work Ben
Jose
Max Ischenko
Here is the error I got:
$ sudo python setup.py egg_info
running egg_info
Traceback (most recent call last):
File "setup.py", line 34, in <module>
""",
File "distutils/core.py", line 151, in setup
File "distutils/dist.py", line 974, in run_commands
File "distutils/dist.py", line 993, in run_command
File "/usr/lib/python2.5/cmd.py", line 117, in ensure_finalized
pass
File "/usr/lib/python2.5/site-packages/setuptools-0.6c6-py2.5.egg/
setuptools/command/egg_info.py", line 85, in finalize_options
File "/usr/lib/python2.5/site-packages/setuptools-0.6c6-py2.5.egg/
setuptools/command/egg_info.py", line 179, in tags
File "/usr/lib/python2.5/site-packages/setuptools-0.6c6-py2.5.egg/
setuptools/command/egg_info.py", line 224, in get_svn_revision
ValueError: max() arg is an empty sequence
I ran paster create doupy -t pylons; allowed it to override all files
it wanted to and now trying to fix them one by one, starting with
setup.py. Here is my setup.py
from ez_setup import use_setuptools
use_setuptools()
from setuptools import setup, find_packages
setup(
name='doupy',
version="1.0",
description="Re-implementation of the developers.org.ua PHP site
in Python",
author="Max Ischenko and contributors",
author_email="m...@developers.org.ua",
url="http://trac.developers.org.ua/dou/",
install_requires=[
"Pylons>=0.9.6rc1",
"SQLAlchemy >= 0.3.9",
"MySQL_python>=1.2.2",
"Mako>=0.1.8", "Beaker>=0.7.4",
"CherryPy>=3.0.1",
"BeautifulSoup", "pudge", "buildutils",
"setuptools>=0.6c6",
],
packages=find_packages(exclude=['ez_setup']),
include_package_data=True,
test_suite = 'nose.collector',
package_data={'doupy': ['i18n/*/LC_MESSAGES/*.mo']},
entry_points="""
[paste.paster_command]
initdb = doupy.websetup:InitDatabaseCommand
phpcode = doupy.websetup:PhpCodeGeneratorCommand
jb-notify = doupy.websetup:JobBoardNotifyCommand
[paste.app_factory]
main=doupy:make_app
[paste.app_install]
main=pylons.util:PylonsInstaller
""",
)
I tried to create an empty project with paster pylons and it doesn't
have this error.
Any ideas?
Max.
Max Ischenko
On Jul 16, 8:38 am, Max Ischenko <ische...@gmail.com> wrote:
> Here is the error I got:
>
> $ sudo python setup.py egg_info
> File "/usr/lib/python2.5/site-packages/setuptools-0.6c6-py2.5.egg/
> setuptools/command/egg_info.py", line 224, in get_svn_revision
> ValueError: max() arg is an empty sequence
Nevermind this; This seems to be a known bug in setuptools which pops
up if you have any uncommitted directory when you run setup.py. As a
workaround, you need to either commit or temporarily revert any
directories marked as 'A' by Subversion ('M' are ok).
Found here: http://pylonshq.com/irclogs/%23pythonpaste/%23pythonpaste.2007-06-04.log.html
Max.
Max Ischenko
On Jul 16, 8:46 am, Max Ischenko <ische...@gmail.com> wrote:
> Nevermind this; This seems to be a known bug in setuptools which pops
> up if you have any uncommitted directory when you run setup.py. As a
> workaround, you need to either commit or temporarily revert any
> directories marked as 'A' by Subversion ('M' are ok).
Added to http://wiki.pylonshq.com/display/pylonsfaq/Home (Distribution
section).
Max.
jose
respect to the Response object. I've done some quick preliminary
testing, and at least between version 9.4 and RC2 my controllers
(simple hello world stuff) were able to still use the Response object
directly. Is this going to remain the case? Or should I migrate all
my projects over to use the new methodology of simply returning a
string? Or is direct use of the Response going to be phased out? Also
it appears that although response is globally available it is not a
global Response object, each action gets its own Response object is
that correct?
Jose
> smime.p7s
> 3KDownload
Philip Jenvey
On Jul 16, 2007, at 11:00 AM, jose wrote:
>
> Again this is a pretty big departure from the previous builds with
> respect to the Response object. I've done some quick preliminary
> testing, and at least between version 9.4 and RC2 my controllers
> (simple hello world stuff) were able to still use the Response object
> directly. Is this going to remain the case? Or should I migrate all
> my projects over to use the new methodology of simply returning a
> string? Or is direct use of the Response going to be phased out? Also
> it appears that although response is globally available it is not a
> global Response object, each action gets its own Response object is
> that correct?
>
We should elaborate on the release notes -- the old way of doing
things will trigger a DeprecationWarning in 0.9.7, and support for it
will go away in the future. In 0.9.6, they actually trigger
PendingDeprecationWarnings. Python hides PendingDeprecationWarnings
by default -- if you'd like to begin migrating your app to use only
the global response right now (recommended), turning on these
warnings can help you find cases of the old syntax. A simple grep can
probably find them all for you, unless third party libraries
(AuthKit?) are involved.
The warnings are triggered during:
o creation of a Response object
o calling render_response
o calling redirect_to with the _response argument
--
Philip Jenvey
Ben Bangert
> Again this is a pretty big departure from the previous builds with
> respect to the Response object. I've done some quick preliminary
> testing, and at least between version 9.4 and RC2 my controllers
> (simple hello world stuff) were able to still use the Response object
> directly. Is this going to remain the case? Or should I migrate all
> my projects over to use the new methodology of simply returning a
> string? Or is direct use of the Response going to be phased out? Also
> it appears that although response is globally available it is not a
> global Response object, each action gets its own Response object is
> that correct?
It will be phased out, deprecated in 0.9.7, and removed either at
1.0, or around 0.9.8 or 0.9.9. For all new project, definitely just
return a string, existing projects can be migrated slowly as the
Response object will remain for several versions to facilitate a
smooth transition.
The global response is just like the global 'c'. It's unique to every
request.
Cheers,
Ben
jose
a warning, so I looks like I may have to migrate my projects anyway,
not a huge deal just something to work on. I think I'll do my
migration within a working env and then just port the new build once I
know it works rather then upgrade my existing code base all at once.
Jose
Ben Bangert
> Well I just tried using render_response and it generates an error not
> a warning, so I looks like I may have to migrate my projects anyway,
> not a huge deal just something to work on. I think I'll do my
> migration within a working env and then just port the new build once I
> know it works rather then upgrade my existing code base all at once.
There shouldn't be errors using render_response, can you post the
traceback of what happened?
Cheers,
Ben
Jose Galvez
First I was testing with pylons-0.9.6rc2dev_r2256-py2.5.egg
The project was created with pylons 0.9.4.1 and then converted after installing rc2 using overwrite the test project was not installed using easy_install simply created and run from the created egg
my controller is:
from rc.lib.base import *
class MainController(BaseController):
def index(self):
res = Response()
res.write('hello world')
return res
def template(self):
return render_response('/main.html')
when I run http://localhost:5000/main I get
 | Warning, your browser does not support JavaScript so you will not be able to use the interactive debugging on this page. |
full traceback
URL: http://localhost:5000/main
Module pylons.error:245 in
respond
>> app_iter = self.application(environ, detect_start_response
)Module pylons.wsgiapp:291 in
__call__
>> return
self.app(environ, start_response)Module beaker.cache:180 in
__call__
>>
return self.app(environ, start_response)Module beaker.session:393 in
__call__
>>
response = self.wrap_app(environ, session_start_response)
Module routes.middleware:104 in
__call__
>> response
= self.app(environ, start_response)Module pylons.wsgiapp:88 in
__call__
>> response = self.dispatch(controller, environ
, start_response)Module pylons.wsgiapp:214 in
dispatch
>>
return controller(environ, start_response)Module rc.lib.base:23 in
__call__
>> return
WSGIController.__call__(self, environ, start_response)Module pylons.controllers:212 in
__call__
>> response = self._dispatch_call()Module pylons.controllers:167 in
_dispatch_call
>> response = self._inspect_call(func)Module pylons.controllers:133 in
_inspect_call
>> result = func(**args)Module rc.controllers.main:5 in
index
>> res = Response()<type 'exceptions.NameError'>: global name 'Response' is not defined
and if I run http://localhost:5000/main/template I get
URL: http://localhost:5000/main/template
Module pylons.error:245 in
respond
>> app_iter = self.application(environ, detect_start_response
)Module pylons.wsgiapp:291 in
__call__
>> return
self.app(environ, start_response)Module beaker.cache:180 in
__call__
>>
return self.app(environ, start_response)Module beaker.session:393 in
__call__
>>
response = self.wrap_app(environ, session_start_response)
Module routes.middleware:104 in
__call__
>>
response = self.app(environ, start_response)Module pylons.wsgiapp:88 in
__call__
>> response = self.dispatch(controller, environ
, start_response)Module pylons.wsgiapp:214 in
dispatch
>>
return controller(environ, start_response)Module rc.lib.base:23 in
__call__
>> return
WSGIController.__call__(self, environ, start_response)Module pylons.controllers:212 in
__call__
>> response = self._dispatch_call()Module pylons.controllers:167 in
_dispatch_call
>> response = self._inspect_call(func)Module pylons.controllers:133 in
_inspect_call
>> result = func(**args)Module rc.controllers.main:10 in
template
>> return render_response('/main.html')<type 'exceptions.NameError'>: global name 'render_response' is not defined
full traceback text version
Jose Galvez
import sys; sys.__plen = len(sys.path)
#./setuptools-0.6c6-py2.5.egg
./paste-1.4-py2.5.egg
./pastescript-1.3.5-py2.5.egg
./pastedeploy-1.3.1-py2.5.egg
./mako-0.1.8-py2.5.egg
./myghtyutils-0.52-py2.5.egg
./nose-0.9.3-py2.5.egg
./simplejson-1.7.1-py2.5.egg
./formencode-0.7.1-py2.5.egg
./myghty-1.1-py2.5.egg
./decorator-2.1.0-py2.5.egg
./beaker-0.7.4-py2.5.egg
./webhelpers-0.3.1-py2.5.egg
./routes-1.7-py2.5.egg
./pylons-0.9.6rc2dev_r2256-py2.5.egg
import sys; new=sys.path[sys.__plen:]; del sys.path[sys.__plen:]; p=getattr(sys,'__egginsert',0); sys.path[p:p]=new; sys.__egginsert = p+len(new)
Ben Bangert
Sure,
First I was testing with pylons-0.9.6rc2dev_r2256-py2.5.egg
The project was created with pylons 0.9.4.1 and then converted after installing rc2 using overwrite the test project was not installed using easy_install simply created and run from the created egg
my controller is:
from rc.lib.base import *
class MainController(BaseController):
def index(self):
res = Response()
res.write('hello world')
return res
def template(self):
return render_response('/main.html')
Jose Galvez
Jose
voltron
I noticed that a few directories are not created when one creates a
new project:
i18n
docs
templates
The models directory is also now called model. Is that all intentional
or is something wrong?
Christoph Haas
> On Jul 16, 2007, at 2:40 PM, Jose Galvez wrote:
>
> Sure,
> First I was testing with pylons-0.9.6rc2dev_r2256-py2.5.egg
>
> The project was created with pylons 0.9.4.1 and then converted after
> installing rc2 using overwrite the test project was not installed using
> easy_install simply created and run from the created egg
>
> Ah, when converting projects I highly recommend using the diff option with
> paster, then backing up the old file and merging changes. This way you don't
> miss important things, which happened in your case.
Is it possible to make that a tad more comfortable? Like running a
predefined command on those two files? vimdiff or kompare come to my
mind. Currently I'm watching the diff (which isn't always easy because
the output is confusing - you have to search thoroughly where the
current diff starts), launching another shell and running vimdiff. I'm
sure that can be improved. Or should I bug Ian about that?
Christoph
Ian Bicking
Isn't it easier at that point just to backup the files and diff the
backup and the new file?
--
Ian Bicking : ia...@colorstudy.com : http://blog.ianbicking.org
: Write code, do good : http://topp.openplans.org/careers
Jose Galvez
Jose
Jose
Christoph Haas
That's a slight improvement over my step-by-step approach I'm doing now.
I'd still prefer an extra option to launch "vimdiff". But I surely can
live without it. Paster's upgrade process is great already. How many
frameworks or environments force you throw away everything...
Cheers
Christoph
Philip Jenvey
What you really want is the ability to interactively merge the
changes on the spot. Command line sdiff can do this. I almost think
Paste should default to using it if it was available (it's on most
unix boxes), but unfortunately, Windows of course doesn't have it.
Maybe one day someone will make a pure python version.
I'm sure there's GUI apps that can do what sdiff does (if not vimdiff
or kompare, I'm not sure what they provide). Allowing a custom diff
would at least let you use any one of these
--
Philip Jenvey
Philip Jenvey
models has indeed moved to model. You might want to switch your app
to use model so you're more in sync with the template, but it's not
at all required. Nothing internally in Pylons assumes you have a
model directory.
docs has moved from the package to the root dir
i18n and templates should be created, but as empty directories. It
must be a bug if they're not. Oddly enough I can't reproduce this
here, even after using an svn export of Pylons (no .svn directory,
nothing in those directories). Are you seeing this on Windows?
Maybe this was changed a recent PasteScript or something (I'm using
PasteScript trunk instead of the last release)?
(FYI: I've been a little tempted to remove the i18n dir, and those
who need it can create it when needed).
--
Philip Jenvey
Evert Rol
>> new project:
>>
>> i18n
>> docs
>> templates
>>
>> The models directory is also now called model. Is that all
>> intentional
>> or is something wrong?
>>
>
> must be a bug if they're not. Oddly enough I can't reproduce this
> here, even after using an svn export of Pylons (no .svn directory,
> nothing in those directories). Are you seeing this on Windows?
Just for the record: same problem here. For me, it's on Mac OS X
(10.4.10, user installed Python 2.5, 0.9.6rc1).
Evert
voltron
getting this on windows 2000 professional. I have created the folders
though, and everything works as expected.
Jonas
On 17 jul, 20:08, Philip Jenvey <pjen...@groovie.org> wrote:
> models has indeed moved to model. You might want to switch your app
> to use model so you're more in sync with the template, but it's not
> at all required. Nothing internally in Pylons assumes you have a
> model directory.
There is a bug respect to that change.
-------------------------------
$ grep -Rw models /usr/local/lib/python2.5/Pylons-0.9.6rc1-py2.5.egg/
models_package = pkg_name + '.models'
-------------------------------
Now must be:
models_package = pkg_name + '.model'
Jonas
On 17 jul, 20:08, Philip Jenvey <pjen...@groovie.org> wrote:
> models has indeed moved to model. You might want to switch your app
> to use model so you're more in sync with the template, but it's not
> at all required. Nothing internally in Pylons assumes you have a
> model directory.
There is a bug about that change.
--------------
$ grep -Rw models /usr/local/lib/python2.5/Pylons-0.9.6rc1-py2.5.egg/
models_package = pkg_name + '.models'
--------------
Now, it mus be:
Jonas
On file:
Pylons-0.9.6rc1-py2.5.egg/pylons/commands.py
And I'm sorry for repeat the message but has been by Google groups.