newbie question on urls.py

[ViX]

According the docs of django, the apps in project should be added in
urls.py like this:
(r'^about/', include('pinax.about.urls')),

But what we see in pinax is something like this instead:
(r'^about/', include('about.urls')),

I assume in setting.py there is some place that the pinax project
folder is added to the python path so that the about app can be added
directly instead of pinax.about, but I cannot find the code. So the
question is what kind of mechanism does pinax use to achieve this
result? Thanks.

[Dougn]

It is actually part of django's management interface. For the live
server I think we add the project directory to the pythonpath.
these apps are in 'incubator' mode and will be moved out of the pinax
directory once they are mature enough. By doing it this way, making
the move does not require rewriting all the files which import the
app.

There is a document on the django wiki about writing reusable apps
which mentions this. I would link it but:
1. It was very very out of date last I liiked (due to all the django
1.0 changes)
2. I cant seem to find it (might have been removed due to #1)

-Doug

[M. N. Islam Shihan]

Hi ViX,

Look through the code of manage.py in pinax folder.

Its a customized version of automatically generated manage.py file
with addition of first few lines.

Those few lines setup all necessary PYTHONPATH using python code,
instead of using the native OS environment's PYTHONPATH which in turns
do the magic.

This is also the reason why you don't need to copy all the contents of
django-hotclub/site-packages to PYTHON_HOME/Lib/site-packages and why
the django-hotclub/apps folder is automagically in your python path.

PS: I liked this approach very much and so changed all my manage.py
files to reflect this paradigm of separating and packaging
dependencies.

Regards,
Shihan

[ViX]

Thanks a lot, Doug and Shihan. I found the site.addsitedir in
manage.py finally.

And Shihan, I agree with you totally, the approach is so elegant in
separating the apps and site dependencies, maybe we should open a
ticket at django-project and ask them to add it as a standard routine.

Best,
V

[M. N. Islam Shihan]

Hi ViX,

You might open a ticket, but though the approach of manage.py is
elegant to many of us along with the pinax developers, I don't think
the django developers will agree to clutter their codes with anything
that are not needed fundamentally :-). They have a well defined
philosophy on their development strategy and you might be interested
on http://www.djangoproject.com/documentation/design_philosophies/#explicit-is-better-than-implicit
. To explain a bit more about their philosophies, you can think about
lack of built-in support for logging into the django framework but it
was intensional and the developers have their explanations at
http://code.djangoproject.com/ticket/55 There always exists a hot
discussion about what should be included/supported in django framework
between the core developers and the community.

For this manage.py customization, you can think it a bit tricky and
require some advanced knowledge (even you were confused about the
black magic that the customized manage.py in pinax is doing and I was
too :-)) but setting/updating PYTHONPATH environment variable is
enough for such needs that can be done even by the naive users/
programmers. And at this point I'll go with the django approach : keep
it easy and simple to understand, keep it consistent, keep it light-
weight. As all code in a django project is written in plain python,
any advanced python programmer will find his way of implementation,
optimization, tweaking/hacking around the django core to meet his
requirements as per her wish and django won't restrict. Also django
doesn't restrict doing and did a lot of black magic within its core,
but the publicly exposed API is extremely simple, so that even non-
programmers (hypothetically) can follow the django tutorial to create
a basic site for them.

This is just my understanding of django philosophies and I might be
wrong.

Regards,
Shihan

[Dougn]

I was also thinking of creating a special app to deal with the python
path.
This would require it to be the first app on the INSTALLED_APPS list
to work properly, and it would need to be part of its management.py
file (and imported in the __init__.py).
I have not done this yet as I don't feel it deserves its own app, and
I also see it as a bit of 'black magic'. At least its not hidden like
the current custom management.py.

If someone feels like turning this into a real app, I will gladly help
them. This is the best approach to getting it added to django core.
If its an app which solves a real problem, has a high amount of
popularity, and is well maintained, the core team will be more
inclined to merge it into the core, either as a contrib app, or as
part of the app loading.

-Doug

On Aug 23, 6:20 am, "M. N. Islam Shihan" <mnis4...@gmail.com> wrote:
> Hi ViX,
>

> You might open a ticket, but though the approach of manage.py is
> elegant to many of us along with the pinax developers, I don't think
> the django developers will agree to clutter their codes with anything
> that are not needed fundamentally :-). They have a well defined
> philosophy on their development strategy and you might be interested

> onhttp://www.djangoproject.com/documentation/design_philosophies/#expli...

> . To explain a bit more about their philosophies, you can think about
> lack of built-in support for logging into the django framework but it

> was intensional and the developers have their explanations athttp://code.djangoproject.com/ticket/55There always exists a hot