project folder with dots

[Exe-5]

Hello, django developers!

On my server every project has it's own folder which name is the same
as project hostname(ex. /home/testsite.com). Bug django don't allow
dots in "project name".

I think we can fix it. For example by avoiding starting import with
project name.

--~--~---------~--~----~------------~-------~--~----~
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@...
To unsubscribe from this group, send email to django-developers+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Kevin Teague]

It's Python which doesn't allow dots in the name of a package,
although it's Django which is putting the name of your project name on
sys.path. This was intentional, see the django.core.management
package:

    # Import the project module. We add the parent directory to
PYTHONPATH to
    # avoid some of the path errors new users can have.

To fix the code is easy enough. But to update all of the relevant
documentation and to require all existing Django deployments to have
to migrate their project structures (or change all of their imports)
to upgrade is a much bigger issue to tackle. In the long run, this
would be a good change, since the current situation is confusing and
can cause a lot of problems - but I think it will take a fair bit of
effort and championing to fix it.

--~--~---------~--~----~------------~-------~--~----~
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@...
To unsubscribe from this group, send email to django-developers+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[tmcnulty1982]

On Mon, Oct 26, 2009 at 8:23 PM, Kevin Teague <kevin@...> wrote:

It's Python which doesn't allow dots in the name of a package,
although it's Django which is putting the name of your project name on
sys.path. This was intentional, see the django.core.management
package:

   # Import the project module. We add the parent directory to
PYTHONPATH to
   # avoid some of the path errors new users can have.

To fix the code is easy enough. But to update all of the relevant
documentation and to require all existing Django deployments to have
to migrate their project structures (or change all of their imports)
to upgrade is a much bigger issue to tackle. In the long run, this
would be a good change, since the current situation is confusing and
can cause a lot of problems - but I think it will take a fair bit of
effort and championing to fix it.

IMHO the project namespace is a useful one to keep around.  If you lose the project name space, then you risk polluting your python path with a lot of generic 'urls' modules, among other things.

If your directory structure on your server includes the domain name, then include the project folder under that.  There's nothing stopping you from housing more generic apps outside the project namespace.

On a related note, an on-going pet peeve of mine is that manage.py leaves '.' on the python path.  This can be confusing for new users who are trying to figure out how to structure their imports.

Tobias

--
Tobias McNulty
Caktus Consulting Group, LLC
P.O. Box 1454
Carrboro, NC 27510
[phone]
http://www.caktusgroup.com

--~--~---------~--~----~------------~-------~--~----~
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@...
To unsubscribe from this group, send email to django-developers+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Exe-5]

> IMHO the project namespace is a useful one to keep around.  If you
> lose the project name space, then you risk polluting your python path
> with a lot of generic 'urls' modules, among other things.

I don't understand why in tutorial all imports contain project name.
I think this is wrong position. In my case I've got one project named
"engine" and three sites using it. If I used import containig "engine"
I would place every site into the folder with the same name, but it's
inconvenient(I think).

My idea is to view site as a number of apps. Each app separated from
others and keeps anything it needs in its own namespace.

What do you think about it?

--~--~---------~--~----~------------~-------~--~----~
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@...
To unsubscribe from this group, send email to django-developers+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Exe-5]

> To fix the code is easy enough. But to update all of the relevant
> documentation and to require all existing Django deployments to have
> to migrate their project structures (or change all of their imports)
> to upgrade is a much bigger issue to tackle.
Thank you for answer.

Do you think it's a good change of django(for ex. for very future
versions) or better leave as it is?

--~--~---------~--~----~------------~-------~--~----~
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@...
To unsubscribe from this group, send email to django-developers+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Kevin Teague]

On Oct 26, 7:23 pm, Tobias McNulty <tob...@...> wrote:
>
> IMHO the project namespace is a useful one to keep around.  If you lose the
> project name space, then you risk polluting your python path with a lot of
> generic 'urls' modules, among other things.
>
> If your directory structure on your server includes the domain name, then
> include the project folder under that.  There's nothing stopping you from
> housing more generic apps outside the project namespace.

Yeah, keeping the project namespace is reasonable, but pushing that
package so that it's inside your project would make more sense.
Instead of having a new project look like:

    mysite/
        __init__.py
        manage.py
        settings.py
        urls.py

Structure a Django project so it has the same layout as a normal
Python project. Which might look something like:

    myinstance/
        setup.py
        settings.py
        bin/
            manage.py
        mysite/
            __init__.py
            urls.py

(not sure where settings.py is supposed to be though - it makes sense
inside the project namespace, but then you shouldn't have user-
editable files inside a package)

>
> On a related note, an on-going pet peeve of mine is that manage.py leaves
> '.' on the python path.  This can be confusing for new users who are trying
> to figure out how to structure their imports.
>

If the structure of a Django project was changed, then you wouldn't
need to take '.' off the path. The default Python path should be fine
without further munging. (Well, I would agree that the Python
interpreter shouldn't be putting '.' on the path to begin with, but
that's done this since before Python 1.5 and I suspect this was done
to make imports less confusing for new users - FWIW Ruby also does
this, but Perl does not). I think the confusion arises with new users
who don't realize that they're already working inside a python package
(well, as an experienced users I find this pretty confusing too ...).
If you don't mix executables and library code together (e.g. manage.py
shouldn't be inside a python package!), then having '.' on the path
doesn't become an issue.

--~--~---------~--~----~------------~-------~--~----~
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@...
To unsubscribe from this group, send email to django-developers+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[tmcnulty1982]

On Tue, Oct 27, 2009 at 4:06 PM, Kevin Teague <kevin@...> wrote:

Structure a Django project so it has the same layout as a normal
Python project. Which might look something like:

   myinstance/
       setup.py
       settings.py
       bin/
           manage.py
       mysite/
           __init__.py
           urls.py

I can't think of any serious objections to your proposal, other than that it's a big change from the way things are done now and I'm not sure what the transition plan would involve.  I'd say, if you are serious about it, create a proposal on the wiki that outlines why this has to happen, when it should happen, if this has been tried before, what the benefits would be, what problems would have to be solved, and how to solve them.

My unqualified opinion is of course subject to veto by any of the powers at be (though I should think anyone is free to make serious, well thought out proposals in the wiki, whatever they might be). :)

Tobias
--
Tobias McNulty
Caktus Consulting Group, LLC
P.O. Box 1454
Carrboro, NC 27510
[phone]
http://www.caktusgroup.com

--~--~---------~--~----~------------~-------~--~----~
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@...
To unsubscribe from this group, send email to django-developers+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---