Howdy!

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/__i nit__.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/sqlobj ect/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/sqlobj ect/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/dat abase.py", line 148, in __get__
    self.set_hub()
  File "/usr/lib/python2.4/site-packages/TurboGears-0.9a4-py2.4.egg/turbogears/dat abase.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

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

On 4/12/06, Matthew Bevan <matt.be...@topfloor.ca> wrote:

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

On 4/12/06, Matthew Bevan <matt.be...@topfloor.ca> wrote:

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

You mention this was running in 0.9a1 and you upgraded to a4. Did you
follow the upgrade proceedure regarding the change in configuration
file format and location?

-Rob

On Friday 14 April 2006 10:10, Rob Haswell wrote:

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.

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

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"

On 4/20/06, Matthew Bevan <matt.be...@topfloor.ca> wrote:

On Wednesday 19 April 2006 21:37, Jorge Vargas wrote:

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/declarativ e.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

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