Template tags and python paths

[Julien]

Hi there,

I'm having a strange problem. Everything works fine with my project
when I test it on my local machine, but it does not when running on my
online server. All because of one little thing, which I suspect has
something to do with the pythonpath.

Here's the structure of the project:

myproject
- myapp1
- myapp2
- templatetags
- __init__.py
- myapp2_tags.py
- __init__.py
- models.py
- settings.py
- etc...


The problem is with "myapp2_tags.py". That file starts with this:
from myapp2.models import MyModel

As I said, it works fine when run locally. But on the server, when it
evaluates in my template "{% load myapp2_tags %}", it crashes and
gives the following error:

"'myapp2_tags' is not a valid tag library: Could not load template
library from django.templatetags.myapp2_tags, No module named models".

The only difference between the local project and the server one is
that the project root name is different. Locally it's "myproject", and
on the server it's "blabla". So the structure on the server is as
follows:

blabla
- myapp1
- myapp2
- templatetags
- __init__.py
- myapp2_tags.py
- __init__.py
- models.py
- settings.py
- etc...

I thought that "myapp2" was not included in the pythonpath, but the
python looks correct:

['/home/myaccount/django', '/home/myaccount/django/blabla', '/home/
myaccount/lib/python2.4', '/usr/local/lib/python2.4/site-packages/
setuptools-0.6c5-py2.4.egg', '/usr/local/lib/python2.4/site-packages/
MySQL_python-1.2.2-py2.4-linux-i686.egg', '/usr/local/lib/
python24.zip', '/usr/local/lib/python2.4/site-packages', '/usr/local/
lib/python2.4', '/usr/local/lib/python2.4/plat-linux2', '/usr/local/
lib/python2.4/lib-tk', '/usr/local/lib/python2.4/lib-dynload', '/usr/
local/lib/python2.4/site-packages/PIL']

BUT, if I add the server's project name to the import statement, it
works:
from blabla.myapp2.models import MyModel

That's the only app (more precisely its templatetag library) that does
not work. Every other app works just fine, so I don't see why this one
fails.

Do you have an idea? I'm really stuck, and the techies at my hosting
company haven't been able to help so far.

Thanks a bunch!

Julien

[Jon Wilson]

Julien wrote:
> Hi there,
>
> I'm having a strange problem. Everything works fine with my project
> when I test it on my local machine, but it does not when running on my
> online server. All because of one little thing, which I suspect has
> something to do with the pythonpath.
>
> Here's the structure of the project:
>
> myproject
> - myapp1
> - myapp2
> - templatetags
> - __init__.py
> - myapp2_tags.py
> - __init__.py
> - models.py
> - settings.py
> - etc...
>
>
> The problem is with "myapp2_tags.py". That file starts with this:
> from myapp2.models import MyModel
>

I've found that in a production environment (apache &c.) that I have to
do a:

from myproject.myapp2.models import MyModel
--
Jon Wilson

[Julien]

Yes, my production environment also runs with apache.

But every other apps work using relative references, starting with the
app names. So all the apps are clearly reachable via the pythonpath.

That template tag library file is the only place where I have to
include the project name in the path... In fact, it does not seem to
find that library, since it looks it in the built it django (see error
message above mentioning "Could not load template
library from django.templatetags.myapp2_tags").

Ideally, I think that the project name should not be included in any
import statement.

Any thoughts?

[Jon Wilson]

Julien wrote:
> Yes, my production environment also runs with apache.
>
> But every other apps work using relative references, starting with the
> app names. So all the apps are clearly reachable via the pythonpath.
>
> That template tag library file is the only place where I have to
> include the project name in the path... In fact, it does not seem to
> find that library, since it looks it in the built it django (see error
> message above mentioning "Could not load template
> library from django.templatetags.myapp2_tags").
>
> Ideally, I think that the project name should not be included in any
> import statement.
>
> Any thoughts?
>

I'd agree with you on that. One of the great things about django apps
is that you can distribute the apps outside of the project. Having to
implicitly call the app path with the project path included like with
apache kind of defeats that purpose. However, at least in the mean
time, as you had found, it works by calling that. I'll have to look and
see if there is a way to fix the templatetags loading to fix that, maybe
by overriding it somewhere.

...

--
Jon Wilson

[Julien]

Yes indeed, I have a problem when distributing my project. I develop
it locally, then commit the changes to an SVN repository. The
production site is a check-out of that repository.

The problem is that the dev and production project roots have
different names (one is "myproject", the other one is "trunk"). So
when I check out the code to the production site, I have to manually
add the production project name ("trunk") to the path to make it work.
Yuk, ugly!

But once again, why does it work fine with all other apps from that
project and not this one??

[Jon Wilson]

Julien wrote:
> Yes indeed, I have a problem when distributing my project. I develop
> it locally, then commit the changes to an SVN repository. The
> production site is a check-out of that repository.
>
> The problem is that the dev and production project roots have
> different names (one is "myproject", the other one is "trunk"). So
> when I check out the code to the production site, I have to manually
> add the production project name ("trunk") to the path to make it work.
> Yuk, ugly!
>
> But once again, why does it work fine with all other apps from that
> project and not this one??
>

although not a permanent fix, maybe try this:

in your production environment settings.py file

import sys
sys.path.append('/path/to/trunk/myapp2')

you might even have to go as far as
sys.path.append('/path/to/trunk/myapp2/templatetags')

but like you said earlier, it really should work by default. :p

--
Jon Wilson