Default project layout / directory structure
Simon Litchfield
Might sound like a triviality, but sometimes it's the little things.....
1. Newcomers -- startproject throws 9/10 into confusion and results in a messy first few projects.
2. Gurus -- each have their own way, what a waste, not DRY.
3. The new breed of django hosting platforms that are on their way -- gives them something to base their tools on.
Why not have a standard way, standard tools, etc etc- built in, batteries included. DRY.
Whether it be a plain old manage.py-friendly directory layout, something virtualenv+pip powered, maybe something like Lincoln Loop's startproject style, Eric Holscher's, or whatever. Lets not go too nuts on directories though, they get tiring (especially in textmate)
Thoughts?
Dmitry Gladkov
when adding new people to the team, especially when it comes to
configuration management - everyone has their own way.
It would be great if there will be at least an official list of best
practices on building Django project layout.
John Debs
some more convention here would make a decision much easier to make.
However, it isn't clear what exactly should be better defined and I
think the first step to a serious proposal would be to figure that
out.
The only example that comes to mind is Pinax's apps/ directory for a
project's internal apps – it's a good convention that many people
already follow. My other gripe has already been taken care of, with
the integration of django-staticfiles.
What other things did you have in mind?
David Cramer
https://github.com/lincolnloop/django-startproject
Kill off all the server configs (though some of it might be cool, like
Fabric integration), and I think it'd make for a pretty good base to
work from if this were to go into core.
Russell Keith-Magee
> Who votes we should come up with a django-blessed 'official' default project layout / directory structure?
Sure -- no disagreement that it would be good to have some common
ground with regards to project layout. All we need now is to agree
what that blessed project layout should be. :-)
And there's the rub. There are a bunch of people with different ideas.
For example, take one idea in your list: virtualenv and pip. For many,
this won't be even slightly controversial. But for others, it will be
a complete show-stopper, because there is many a site that enforces a
'package manager only' approach to system adminstration.
So, we have to tread carefully here. At some level, we may just need
to make an executive BDFL call. However, a BDFL isn't going to make a
call until there is a proposal (or three) on the table. What we need
is for someone to drive the discussion and make this happen so that we
are in a position to actually bless something.
For the record, this isn't a new idea, either. Django's tutorial has
said "more coming soon" for as long as I've been involved with Django.
At several times over the last couple of years, there have been
discussions about adding step 5, 6 and more. One of the ideas that is
kicking around is to talk more about project structure, showing how a
reusable app fits into the picture; how pip, virtualenv, tools like
fabric and chef fit into the picture; and so on.
However, writing tutorials takes time, and writing good tutorials takes longer.
So -- if you build it, they will come. Someone just needs to build it :-)
Yours,
Russ Magee %-)
br
to Django I can endorse increased standardization & documentation in
the area of project management & structuring. I have struggled to
figure out the right set up for our project(s). I have also tried to
grapple with coupling django projects, DRY, & pluggablity with a
workable git setup (one repo, or many? submodules?), along with
setting up virtualenv along with pip & fabric for a large application
consisting of multiple projects.
I realize this isn't the forum for my project structure as a django
user (I've posted on that in django-users), but grappling with project
management has been puzzling for me, being new to django, and wanted
to provide my perspective to developers and encourage this thread. If
more guidelines exist, more people may find themselves doing things in
standard ways rather than coming up with unique structures because
manage.py startproject doesn't quite fit their needs.
Ben
On Mar 14, 5:46 pm, Russell Keith-Magee <russ...@keith-magee.com>
wrote:
> > Who votes we should come up with a django-blessed 'official' default project layout / directory structure?
>
> Sure -- no disagreement that it would be good to have some common
> ground with regards to project layout. All we need now is to agree
> what that blessed project layout should be. :-)
>
> And there's the rub. There are a bunch of people with different ideas.
> For example, take one idea in your list: virtualenv and pip. For many,
> this won't be even slightly controversial. But for others, it will be
> a complete show-stopper, because there is many a site that enforces a
> 'package manager only' approach to system adminstration.
>
> Russ Magee %-)
Simon Litchfield
wrote:
> > Who votes we should come up with a django-blessed 'official' default project layout / directory structure?
>
> Sure -- no disagreement that it would be good to have some common
> ground with regards to project layout. All we need now is to agree
> what that blessed project layout should be. :-)
manage.py
--conf
----settings.py
----settings_dev.py
--lib
----other_app1
----other_app2
--my_app1
--my_app2
--media
--templates
--templatetags (project tags, non-app specific, if you have any)
--views.py (project views, non-app specific, if you have any)
--urls.py (project urls, non-app specific)
Or maybe this --
manage.py
--conf
----settings.py
----settings_dev.py
----(wsgi files)
--lib
----other_app1
----other_app2
--project
----my_app1
----my_app2
----templatetags (project tags, non-app specific, if you have any)
----views.py (project views, non-app specific, if you have any)
----urls.py (project urls, non-app specific)
--media
----css
----img
----js
----uploads
--templates
This way we keep our pythons separate from our chickens.
Also to suggest a preferred media structure or not- at least a
centralised uploads / var media folder would be good practice I think,
at least from provisioning and permissions etc point of view.
Thoughts? These are just a few suggestions to get the conversation
started!
Tai Lee
things simple, this is what I think we'd have:
myapp1/
myapp2/
myproject/
-django.wsgi.sample
-manage.py
-management/
--commands/
---myproject_mycommand.py.sample
-media/
--myproject/
---readme.txt
-models.py
-settings.py
-static/
--myproject/
-templates/
--myproject/
-templatetags/
--myproject_tags.py.sample
-urls.py
-vendor/
--readme.txt
-views.py
otherapp1/
otherapp2/
Basically it's what we have now plus three things, samples of common
optional files (which could include a link to the relevant docs page
so people can get started right away), suggestions for naming
conventions (use the app name as a prefix to avoid clashes with other
apps) and a vendor folder for 3rd party reusable apps:
- a sample wsgi wrapper
- a sample management command showing that management commands should
be prefixed with the app name to avoid clashes with other apps
- a readme.txt reminding people that the media folder is for uploaded
content (not static content) and suggesting that they use an
`upload_to` value of `app_name/model_name/field_name` on their model
file and image fields as a starting point
- a static folder showing that static content should be placed in a
folder named after the app to avoid clashes with other apps
- a templates folder showing that templates should be placed in a
folder named after the app to avoid clashes with other apps
- a sample template tag library showing that template tag libraries
should be prefixed with the app name to prevent clashes with other
apps and suffixed with "_tags" to prevent quirky import issues (e.g.
myproject_tags.py, myproject_form_tags.py)
- a vendor folder that is automatically added to the python path (at
the beginning, or after the project folder) and a readme.txt
explaining that 3rd party reusable apps or specific versions of apps
that exist elsewhere on the system should be placed here and imported
with `from otherapp... import...`
Another thing to point out is that a "project" is just an "app" with a
settings.py file, a media folder, and perhaps a vendor folder.
My big thing is that we should drive home the importance of decoupling
or loosely coupling your apps. Unless you are 100% certain that you
will ALWAYS want to bundle an app with your project AND and that you
will NEVER want to use an app without your project, your other apps
should exist as separate modules that can be placed anywhere on your
python path.
If Django were to automatically add the vendor folder to the python
path as the second folder (after the folder containing your
settings.py file), it would provide a standard way for users to
include specific versions of 3rd party apps or their own reusable apps
that may or may not be installed elsewhere on the hosting environment.
For example, bundling a specific version of Django to be used even if
another version of Django is already installed.
I've recently decoupled a bunch of apps that were initially too
tightly coupled to a common library that I use in most projects. As
the apps grew and as we started working on more projects, it became
troublesome to have to bundle this increasingly large library of apps
when only a handful would be used by a project, and there were also
times when I'd have liked to make use of just one in a project that a
3rd party had source code access to without giving them access to
everything.
I wish that I'd learned sooner to always try and build smaller,
simpler apps with more limited and specific scope that were decoupled
or more loosely coupled to other apps so that they could be more
easily reused. Anything that Django can do to make this point more
obvious would be a good thing.
Cheers.
Tai.
Tom Evans
I strongly disagree here. Django shouldn't be doing magic with my
PYTHONPATH, if I want stuff in my PYTHONPATH, I'll darn well put it
there.
>
> Another thing to point out is that a "project" is just an "app" with a
> settings.py file, a media folder, and perhaps a vendor folder.
No, not really. Projects don't have models, for a start.
>
> My big thing is that we should drive home the importance of decoupling
> or loosely coupling your apps. Unless you are 100% certain that you
> will ALWAYS want to bundle an app with your project AND and that you
> will NEVER want to use an app without your project, your other apps
> should exist as separate modules that can be placed anywhere on your
> python path.
>
> If Django were to automatically add the vendor folder to the python
> path as the second folder (after the folder containing your
> settings.py file), it would provide a standard way for users to
> include specific versions of 3rd party apps or their own reusable apps
> that may or may not be installed elsewhere on the hosting environment.
> For example, bundling a specific version of Django to be used even if
> another version of Django is already installed.
This issue is well solved in the python world. It's called virtualenv.
Django should not be replacing standard python processes with Django
magic.
>
> I've recently decoupled a bunch of apps that were initially too
> tightly coupled to a common library that I use in most projects. As
> the apps grew and as we started working on more projects, it became
> troublesome to have to bundle this increasingly large library of apps
> when only a handful would be used by a project, and there were also
> times when I'd have liked to make use of just one in a project that a
> 3rd party had source code access to without giving them access to
> everything.
>
> I wish that I'd learned sooner to always try and build smaller,
> simpler apps with more limited and specific scope that were decoupled
> or more loosely coupled to other apps so that they could be more
> easily reused. Anything that Django can do to make this point more
> obvious would be a good thing.
>
Yep, that is particularly important when writing re-usable code. It's
not just true of 'apps', but also of python libraries, which a django
app is a particular example of.
Cheers
Tom
Carl Meyer
On 03/17/2011 05:36 AM, Tom Evans wrote:
> I strongly disagree here. Django shouldn't be doing magic with my
> PYTHONPATH, if I want stuff in my PYTHONPATH, I'll darn well put it
> there.
Hear, hear! I'm only a weak +0 on the entire idea of documenting a
"standard" project layout, as I think it's highly idiosyncratic and
dependent on the nature of the project. But I am strongly -1 on any
proposal to introduce any more sys.path-mangling anywhere in Django. I'm
eager to remove the bit that is already there.
Carl
Calvin Spealman
--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-d...@googlegroups.com.
To unsubscribe from this group, send email to django-develop...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
--
Read my blog! I depend on your acceptance of my opinion! I am interesting!
http://techblog.ironfroggy.com/
Follow me if you're into that sort of thing: http://www.twitter.com/ironfroggy
Russell Keith-Magee
Likewise. I'd like to spend some time in the 1.4 cycle looking at this
problem; it's an annoying wart, results in startup code that is a lot
more complex (and brittle) than it should, and causes all sorts of
confusion when it comes time to deploy your project.
Yours,
Russ Magee %-)
Alex Kamedov
-1 On django manipulating PYTHONPATH
+1 On encouraging people to keep their applications out of their project!
--
David De La Harpe Golden
> On Thu, Mar 17, 2011 at 9:26 PM, Calvin Spealman <ironf...@gmail.com>wrote:
>
>> -1 On django manipulating PYTHONPATH
>
> +1 On encouraging people to keep their applications out of their project!
>>
> I think, it's a good idea to add new option to startapp command for create
> Django application out the project and has structure compatible with
> setuptools and distutils:
That sounds handy... I'm in the process of recasting all reusable apps
here to use distutils or distribute ([1][2]) properly "manually". It's
not especially hard, but I wish they'd started out that way because we
have like 14+ of them by now. (Probably mostly never even to be
released, but to be hosted on an internal pypi-alike instance (hey
djangopypi [3]) for centralised deployment).
Aside/bikeshed:
One minor weird Python:TMTOWTDI detail I've noticed arising from the
precise names you chose for your example:
It seems to be a rule perhaps more honoured in the breach - right now,
the pypi list has a very strange mix of lowercaseruntogether, lisp-like
dashes, underscore_separated_lowercase, dot.separated.names, Even Space
Separated, CamelCase,..., - but there does seem to be a current
recommendation that the distribution/project names ("Django") themselves
as distinct from python package names ("django") should be CamelCase [4].
The "django-" prefix in the name of reusable django app distributions
has already emerged as quite widely (but not universally) used, too, and
is obviously lisp-like-dashes not CamelCase, but really I'm not clear
that it's necessary for django apps to have django- in the distribution
name, they'd presumably be categorised Framework::Django anyway if
logged on PyPI. [5]
[1]
http://guide.python-distribute.org/introduction.html#current-state-of-packaging
[2] http://packages.python.org/distribute/
[3] http://pypi.python.org/pypi/djangopypi/
[4]
http://guide.python-distribute.org/creation.html#basics-creating-and-distributing-distributions
[5] http://pypi.python.org/pypi?:action=browse&show=all&c=523
Markus Gattol
--template switch.
sirex
> Who votes we should come up with a django-blessed 'official' default project layout / directory structure?
creating django-starter project. django-starter is already used by 10
or more projects and it seems, that this solution works.
https://bitbucket.org/sirex/django-starter/src
The main idea of this project is to make possible to prepare
development and production environments using just one command:
make # for development environment
make deploy # for production environment
django-starter is influenced by http://jacobian.org/writing/django-apps-with-buildout/
Markus Gattol
> creating django-starter project. django-starter is already used by 10
> or more projects and it seems, that this solution works.
>
> https://bitbucket.org/sirex/django-starter/src
This one does https://github.com/epicserve/django-environment
Markus Gattol
> creating django-starter project. django-starter is already used by 10
> or more projects and it seems, that this solution works.
>
> https://bitbucket.org/sirex/django-starter/src
sirex
> That does not seem to work with pip and virtual environment, does it?
> This one doeshttps://github.com/epicserve/django-environment
Matt Harasymczuk
myproject
- apps
- libs
- conf
- public
- settings.py
- urls.py
conf:
- production.py
- test.py
- dev.py
libs:
- all third party modules
public:
- media
- static
- admin
- django.wsgi
each app structure:
- admin
- backends
- commands
- context_processors
- decorators
- feeds
- forms
- management
- managers
- middleware
- models
- signals
- sitemaps
- templates
- templatetags
- tests
- urls.py
- views
most of above are unnecessary for simple project, so I suggest to add
a switch to manage.py startapp to do this.
I am suggesting that app should have directories not files...
When you develop large app (CRM) you have to write tens of models,
with overriding saves, __unicode__, Meta and custom methods it becomes
hard to read and maintain
I solve this by adding app_label to each of my models in separate
files and models/__init__.py imports all models. It works like a
charm.
I think it should be by default :}
I created skel/django/project and skel/django/app folders, where I
have this file structure
when I start project I simply copy folder, rename it, and adjust
--
Matt Harasymczuk
www.matt.harasymczuk.pl