Ticket #1888 (new defect)

Opened 3 months ago

Last modified 1 month ago

top_level_dir (in config) don't resolve correctly in namespace packages

Reported by: guest Assigned to: anonymous
Priority: normal Milestone: __unclassified__
Component: TurboGears Version: 1.0.5
Severity: normal Keywords: namespace
Cc:

Description

I have a turbogears website that I would like to deploy within my conventional namespace. I have already, for example, myns.util. I also have the turbogears website with a package of myns.website.

I have altered the default paste template to create myns.website. I believe I have implemented the namespace correctly, as most everything works as expected, except... static content fails to render and an error is reported:

2008-07-08 20:24:27,438 cherrypy.msg INFO DEBUG: NOT FOUND file: C:/Program Files/Python/lib/site-packages/myns.util-0.2dev_r572-py2.5.egg/myns/website/static\images/under_the_hood_blue.png

or if a development link was set for myns.util:

2008-07-08 19:52:07,075 cherrypy.msg INFO DEBUG: NOT FOUND file: c:/projects/myns.util/src/myns/website/static\images/under_the_hood_blue.png

Note that turbogears is using the deployment path for myns.util, not myns.website, so the incorrect value must be being set in top_level_dir and package_dir.

The error occurs if myns.util is either installed or linked using "setup develop". If I remove all projects that share the same namespace, static content renders properly in myns.website.

It's possible that under certain conditions, the myns.website would take precedence, but I'm not sure what these conditions would be.

Note that the issue occurs regardless of whether myns.website is registered with setuptools (i.e. via "setup develop"). Furthermore, note that if both namespace packages are registered, they are both properly accessible through import.

from myns.site import * from myns.util import *

This issue is related to, although distinct from, #12.

Attachments

myns.site.zip (227.9 kB) - added by guest on 08/29/08 14:13:23.
A namespace-based tg project

Change History

07/14/08 20:34:07 changed by guest

Correction: top_level_dir appears to be the only variable that is affected by this issue. package_dir does resolve correctly.

So, a workaround for the static content issue is to change:

static_filter.dir = "%(top_level_dir)s/site/static"

to

static_filter.dir = "%(package_dir)s/static"

(and similarly for /favicon.ico).

It seems to me this is the better variable choice (for app.cfg in the template) anyway.

07/14/08 20:37:05 changed by guest

  • summary changed from top_level_dir and package_dir (in config) don't resolve correctly in namespace packages to top_level_dir (in config) don't resolve correctly in namespace packages.

So the issue is that top_level_dir is being calculated from the location for the "myns" package, which actually appears in a number of locations (physically). Therefore, top_level_dir should probably be calculated using a different technique.

08/28/08 16:01:29 changed by Chris Arndt

Can you please provide an example project (together with the necessary namespace packages) that demonstrates this problem? I don't quite understand the problem. If I can look at the code, it might be easier to understand.

08/28/08 16:19:47 changed by Chris Arndt

  • milestone set to __unclassified__.

08/29/08 14:13:23 changed by guest

  • attachment myns.site.zip added.

A namespace-based tg project

08/29/08 14:22:33 changed by guest

I have attached a sample TG 1.0.5 project that was quickstarted using:

tg-admin quickstart -e -t tggenshi

It was originally called myns_site (myns stands for "my namespace" and site is the web site in this namespace).

I then converted the quickstarted project into a namespace-aware project. The different between the original is included in a diff file in the zip archive.

Note that when one starts the application as written, the error is exemplified. If one alters app.cfg to use the %(package_dir)s string, then the static content loads correctly. This indicates to me that %(package_dir)s may be the correct variable to use in all cases.

To further complicate matters, one may also install another package in the myns namespace. Simple examples are available from http://code.google.com/p/python-nose/issues/detail?id=197. Installing myns.projA with the attached TG site will cause TG to search in the myns.projA for static content, and not in myns.site. In particular, top_level_dir will refer to something like "c:\Python\lib\site-packages\myns.projA\myns".

I will be gone for the weekend but back on Tuesday. Let me know if I can provide any clarification for this issue.