On Sep 15, 1:45 am, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> On 9/14/07, Graham Dumpleton <[EMAIL PROTECTED]> wrote:
>
>
>
> > Seems I am never going to win on this issue. Latest updates have seen
> > the issue closed without any change being made. I also again can not
> > put updates on the ticket since I seem to be completely blacklisted or
> > something from Django site as I always get 'Submission rejected as
> > potential spam (Akismet says content is spam)' no matter what I do. I
> > give up. Someone else can answer user questions where this is the
> > issue now. :-(
>
> Hi Graham,
>
> I have no idea why you would be blacklisted. I presume you have
> created a Trac account and you are using it to submit the tickets?
>
> Regarding that particular ticket - yes, it was closed without any
> change being made - that's because we couldn't work out what change
> you thought needed to be made. We already talk about the mod_python
> PYTHONPATH, and how it relates to the way you reference applications.
> Malcolm and I couldn't see what we could improve, short of inserting a
> copy of the Python manual on how paths and imports work.
>
> Essentially, we're looking for a specific suggestion here. Obviously,
> your experience fielding these questions has been that there is
> something missing/misleading in the existing text - could you have a
> bash at a fix? It doesn't have to be perfect - just an indication of
> what sort of change you would like to see.
I thought I was being reasonably clear in what I have previously
posted. In the documentation it only talks about examples like 'import
blogroll' as being a trigger for also adding the site directory to
PythonPath. It does not mention anything about 'urls.py' and when a
dotted module path is listed in the target string associated with a
rule. In other words, a new user, or one not that knowledgeable about
Django is probably not going to realise that when you have:
(r'^articles/(\d{4})/$', 'blogroll.views.year_archive'),
that under the covers the string 'blogroll.views.year_archive'
automagically results in the equivalent of:
import blogroll.views
and that as a consequence it will not be found if the site directory
wasn't added to PythonPath when using mod_python.
Now it may be the case that since I don't actually use Django that I
am the one who doesn't understand here and that Django somehow also
automagically ensures that a search is done relative to the directory
where urls.py is located for the module identified by the target
string, but didn't think this was the case since the suggestion of
adding site directory always seemed to solve the problem for people
dropping the site name from the rule target string. And yes I know it
does work when using development server, and that is because that
directory is made the current working directory of the application and
thus it searches relative to it automatically. This is not the case by
default with mod_python though.
Thus, all was wanting was a reference to mapping rules in urls.py
file. If you don't want to be explicit in including another example
for setting PythonPath, then a change along the lines of:
"""With this path, 'import weblog' and 'import mysite.settings' will
both work. If you had 'import blogroll' in your code somewhere, or
'blogroll' was the leading component of the target string in a mapping
rule listed in 'urls.py' and not the site name 'weblog', and
'blogroll' lived under the 'weblog/' directory, you would also need to
add '/usr/local/django-apps/weblog/' to your PythonPath. Remember: the
parent directories of anything you import directly must be on the
Python path."""
would be a good start.
I know it is a fine distinction, but it is the rules in urls.py that
more often than not seem to trip people up, not the explicit use of
the 'import' statement in code given as an example. Remember that most
users are not Python exports or will understand how Django works under
the covers.
FWIW, I believe the documentation should just say to always add both
parent and site. That way it properly mirrors what the development
server does. Doing that would avoid this whole argument as things
would just work like they did with the development server.
As to not being able to post to tickets, I have always just used my
email address and it has worked. Ie., I do not have an account. The
ticket page says to use 'Your email or username' with an option of
creating a username only if you want it. It was only a few weeks back
that use of email address stopped working. If there has been some
policy change that you must have an account now, the page really needs
to be updated to reflect that. If there hasn't been a change, then
Trac must be recording somehow that my email address is a spam
source. :-(
Graham
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
