Upgrading to 0.9a4 breaks my CMS badly.
Matthew Bevan
Running 0.9a1 my CMS works fine in 'setup.py develop' mode, allowing me to create a site with a sitetemplate and start adding content. Brilliant. But after upgrading to 0.9a4 and updating the occasional moved function (turbogears.jsonify to turbojson.jsonify, for example), I can no longer even run tg-admin, as it bombs with the following traceback:
Traceback (most recent call last):
File "/usr/local/bin/tg-admin", line 7, in ?
sys.exit(
File "/usr/lib/python2.4/site-packages/setuptools-0.6a11-py2.4.egg/pkg_resources.py", line 236, in load_entry_point
return get_distribution(dist).load_entry_point(group, name)
File "/usr/lib/python2.4/site-packages/setuptools-0.6a11-py2.4.egg/pkg_resources.py", line 2097, in load_entry_point
return ep.load()
File "/usr/lib/python2.4/site-packages/setuptools-0.6a11-py2.4.egg/pkg_resources.py", line 1830, in load
entry = __import__(self.module_name, globals(),globals(), ['__name__'])
File "/usr/lib/python2.4/site-packages/TurboGears-0.9a4-py2.4.egg/turbogears/__init__.py", line 18, in ?
ext = entrypoint.load()
File "/usr/lib/python2.4/site-packages/setuptools-0.6a11-py2.4.egg/pkg_resources.py", line 1830, in load
entry = __import__(self.module_name, globals(),globals(), ['__name__'])
File "/home/mbevan/Projects/TG-Content/content/__init__.py", line 76, in ?
startup()
File "/home/mbevan/Projects/TG-Content/content/startup.py", line 31, in startup
module = component.load()
File "/usr/lib/python2.4/site-packages/setuptools-0.6a11-py2.4.egg/pkg_resources.py", line 1830, in load
entry = __import__(self.module_name, globals(),globals(), ['__name__'])
File "/home/mbevan/Projects/TG-Content/content/components/__init__.py", line 10, in ?
import model
File "/home/mbevan/Projects/TG-Content/content/components/model.py", line 41, in ?
class Page(Atom):
File "/usr/lib/python2.4/site-packages/SQLObject-0.7.1dev_r1588-py2.4.egg/sqlobject/declarative.py", line 108, in __new__
cls.__classinit__(cls, new_attrs)
File "/usr/lib/python2.4/site-packages/SQLObject-0.7.1dev_r1588-py2.4.egg/sqlobject/main.py", line 748, in __classinit__
if not connection and not getattr(cls, '_connection', None):
File "/usr/lib/python2.4/site-packages/TurboGears-0.9a4-py2.4.egg/turbogears/database.py", line 148, in __get__
self.set_hub()
File "/usr/lib/python2.4/site-packages/TurboGears-0.9a4-py2.4.egg/turbogears/database.py", line 166, in set_hub
raise KeyError, "No database configuration found!"
KeyError: 'No database configuration found!'
I've uploaded a WIP copy of my CMS at the following URL:
1.1MB http://www.gothcandy.com/tg-content/releases/TG-Content-0.9a4.tar.bz2
Previousally if the DB connection didn't exist, it just silently ignored everything. (While working perfectly fine on a properly set up tg-admin shell.) Why has this changed? Any difference in SVN?
- Matthew
Matthew Bevan
> create a site with a sitetemplate and start adding content. Brilliant.
> But after upgrading to 0.9a4 and updating the occasional moved function
> (turbogears.jsonify to turbojson.jsonify, for example), I can no longer
> even run tg-admin, as it bombs with the following traceback:
Further investigation narrows it down to my startup code automatically
importing the model for the CMS component libraries. The CMS model works
fine, with no errors while running a clean tg-admin with lines 25 to 27 of
TG-Content/setup.py commented out - i.e. without CMS components.
What is the reccomended way of including models from EGG entry points?
- Matthew
Kevin Dangoor
> Running 0.9a1 my CMS works fine in 'setup.py develop' mode, allowing me to create a site with a sitetemplate and start adding content. Brilliant. But after upgrading to 0.9a4 and updating the occasional moved function (turbogears.jsonify to turbojson.jsonify, for example), I can no longer even run tg-admin, as it bombs with the following traceback:
>
> raise KeyError, "No database configuration found!"
> KeyError: 'No database configuration found!'
>
> I've uploaded a WIP copy of my CMS at the following URL:
>
> 1.1MB http://www.gothcandy.com/tg-content/releases/TG-Content-0.9a4.tar.bz2
>
> Previousally if the DB connection didn't exist, it just silently ignored everything. (While working perfectly fine on a properly set up tg-admin shell.) Why has this changed? Any difference in SVN?
I can see why it fails, but I don't know of something in the TG code
that would cause this. I wonder if something has changed in SQLObject
(seems surprising, though, given that there hasn't been *that* much
activity that I've seen on the 0.7-bugfix branch).
The set_hub implementation is basically the same that was there 300
revisions ago. If this worked in 0.9a1, it would seem that SQLObject
is, for some reason, asking for the connection where it previously
hadn't been. That's my initial take after a quick look at things.
Kevin
Kevin Dangoor
I didn't see anything that immediately struck me as wrong about your
use of entry points. (I did notice that it was on import of the
component model that it failed, but I didn't spot a difference in how
your component model and main models were set up that would cause
SQLObject to trigger a request for a connection.
Kevin
Rob Haswell
follow the upgrade proceedure regarding the change in configuration
file format and location?
-Rob
Matthew Bevan
The upgrade instructions do not matter for my CMS package as the CMS package
has no internal configuration of its own. It relies on the configuration of
the "host" TG application.
Nice try, though! ;^)
- Matthew, still hacking.
Jorge Vargas
please do as it says in http://www.turbogears.org/preview/download/upgrade.html
under "Updating from 0.9a1 to 0.9a2" this still applies for your 0.9a4.
By the way Kevin that title should be change to "Updating from 0.9a1 to 0.9a2 or later"
Matthew Bevan
> yes that is exactly waht Rob was talking about there was a change in the
> file extensions in 0.9a1 which was reverted in 0.9a2
Let me clarify then. Without having -ANY- TG site set up, say, just after getting the latest SVN and friends set up in "develop" mode, I run 'sudo python setup.py deveop' in my TG-Content package. I then enter a scratch directory and run tg-admin with no arguments. It dies.
The problem has to do with how TurboGears attempts to automatically provide a DB connection. It does so (and of course dies if no configuration is set up) but the strangeness is that only InheritableSQLObjects are causing the error.
From what I can tell of Identity, how an application accesses the configuration setting has not changed, only how that setting is set in the first place.
After some experimenting with the "comment-out-all-then-work-backwards" school of debugging I have narrowed the problem down.
After dropping content.components registration from setup.py (and re-installing) the following in my content.model:
class Test(InheritableSQLObject):
pass
class Bob(Test):
pass
Reproduces the error thus:
Traceback (most recent call last):
File "/usr/bin/tg-admin", line 7, in ?
sys.exit(
File "/usr/lib/python2.4/site-packages/setuptools-0.6a11-py2.4.egg/pkg_resources.py", line 236, in load_entry_point
return get_distribution(dist).load_entry_point(group, name)
File "/usr/lib/python2.4/site-packages/setuptools-0.6a11-py2.4.egg/pkg_resources.py", line 2097, in load_entry_point
return ep.load()
File "/usr/lib/python2.4/site-packages/setuptools-0.6a11-py2.4.egg/pkg_resources.py", line 1830, in load
entry = __import__(self.module_name, globals(),globals(), ['__name__'])
File "/home/mbevan/Projects/turbogears/turbogears/__init__.py", line 18, in ?
ext = entrypoint.load()
File "/usr/lib/python2.4/site-packages/setuptools-0.6a11-py2.4.egg/pkg_resources.py", line 1830, in load
entry = __import__(self.module_name, globals(),globals(), ['__name__'])
File "/home/mbevan/Projects/TG-Content/content/__init__.py", line 23, in ?
from content import controllers, model, widgets
File "/home/mbevan/Projects/TG-Content/content/model.py", line 16, in ?
class Bob(Test):
File "/home/mbevan/Projects/turbogears/thirdparty/sqlobject/sqlobject/declarative.py", line 108, in __new__
cls.__classinit__(cls, new_attrs)
File "/home/mbevan/Projects/turbogears/thirdparty/sqlobject/sqlobject/main.py", line 748, in __classinit__
if not connection and not getattr(cls, '_connection', None):
File "/home/mbevan/Projects/turbogears/turbogears/database.py", line 148, in __get__
self.set_hub()
File "/home/mbevan/Projects/turbogears/turbogears/database.py", line 166, in set_hub
raise KeyError, "No database configuration found!"
KeyError: 'No database configuration found!'
Lines 748-753 of sqlobject/main.py attempt to pull a connection instance from the class's _connection property, then from '__connection' in the the module containing the class. The act of testing the boolean value of 'connection' (set to the DB hub) attempts to open a connection, unless I am mistaken.
*sigh* I don't know what changed, but I will again try to narrow down which specific SVN change caused the problem. Time for some more coffee...
What revision in SVN was 0.9a0?
- Matthew
Matthew Bevan
> specific SVN change caused the problem. Time for some more coffee...
It works on SVN 1076, fails on 1081 with a slightly different traceback:
Traceback (most recent call last):
File "/usr/bin/tg-admin", line 7, in ?
sys.exit(
File "/usr/lib/python2.4/site-packages/setuptools-0.6a11-py2.4.egg/pkg_resources.py", line 236, in load_entry_point
return get_distribution(dist).load_entry_point(group, name)
File "/usr/lib/python2.4/site-packages/setuptools-0.6a11-py2.4.egg/pkg_resources.py", line 2097, in load_entry_point
return ep.load()
File "/usr/lib/python2.4/site-packages/setuptools-0.6a11-py2.4.egg/pkg_resources.py", line 1830, in load
entry = __import__(self.module_name, globals(),globals(), ['__name__'])
File "/home/mbevan/Projects/turbogears/turbogears/__init__.py", line 4, in ?
from turbogears.controllers import expose, flash, validate, redirect, \
File "/home/mbevan/Projects/turbogears/turbogears/controllers.py", line 16, in ?
from turbogears.validators import Invalid
File "/home/mbevan/Projects/turbogears/turbogears/validators.py", line 109, in ?
class FieldStorageUploadConverter(validators.FancyValidator):
NameError: name 'validators' is not defined
SVN 1087 is where the error becomes the more familiar "No database configuration found!". It also happens to be where FastData was removed from the core and where validators.FancyValidator is replaced with FancyValidator, thus correcting the first error.
Error is introduced in 1081, but is masked by a bug solved in 1087.
I'll hand-apply the differences block by block to see exactly what breaks it.
- Matthew