Moving things around so this looks like python code, not garbage

[davedash]

So, I decided to get the ball rolling on this. Looking for input from @fwenzel, @kumar303 and if he's around @andymckay in particular.

I'm unsure about the vendor* libs... Should I move them under myproject as well?

If I don't I need to adjust funfactory to find them. This should not get committed as-is.

Thanks

[kumar303]

I think it's pretty convenient to cd into a dir and type ./manage.py test or runserver so I wouldn't want to lose that as the default layout (personally). However, it should be possible to support both types of layouts. Does everything in funfactory still work with the myproject layout? One goal of funfactory is that you don't have to rely on the playdoh repo for its layout and future code changes. If funfactory needs a change to support nested projects then let's fix it.

[Osmose]

Is it possible to put media and migrations under myproject as well? They're tied close enough to the app that I think it should be moved down as well to keep as many site-specific things outside of myproject as possible.

What would we have to change if we rename myproject t something else?

[washort]

+1, this is how python projects should look.

For further reference: http://as.ynchrono.us/2007/12/filesystem-structure-of-python-project_21.html

[Osmose]

+1 for the idea, definitely.

[erikrose]

My cafeteria-style selection:

• I like Dave's proposal, as a general goal, even though there are certain specifics I'd change. I like it because it moves random stuff (media, docs, bin) out of an importable Python namespace. I'm not 100% gung ho, and I'm still figuring out why that is.
• Like Kumar, I like manage.py at the root, though it kinda kills the "the normal Django project stuff is in myproject" semantic (which should be documented somewhere, and myproject should perhaps be called my_django_project, and the user should rename it but invariably won't). Git can version softlinks (curse Windows!), so we could do that, failing all else. I wonder if the path chicanery would still work.

[davedash]

• Funfactory could include a sanity checking mechanism that warns if you didn't rename your project
• manage.py could tap into myproject.manage.py

[robhudson]

I agree that it makes sense the the Django project would be in a folder itself, and other top level folders would contain the other various bits that wouldn't make sense to import, like static assets, etc. Personally, I was actually surprised at first to see manage.py at the root of zamboni.

[tofumatt]

For what it's worth, Django 1.4 seems to be going in this direction too: https://docs.djangoproject.com/en/dev/releases/1.4/#updated-default-project-layout-and-manage-py

[tofumatt]

Oh, and I really don't like the idea of doing git softlinks. It feels like fail and isn't good for Windows folks. Git, at its core, it about tracking files (hence its inability to store empty folders) and adding a symlink feels like you're committing directory structure rather than content.

[peterbe]

I think the killer argument is that of @tofumatt; that django 1.4 is doing exactly what davedash wants to achieve. Namely to put settings, urls.py, etc. in a "mysite" sub directory and just leave manage.py in the root folder.

I'm all for it! Cleaner, more pythonic-package feeling, no more weird ROOT_URLCONF hacks in settings.
As long as I can name the repo the same name as the site.

[kumar303]

I want playdoh to be more like the 1.4 layout (and more pythonic) but the proposed layout change here means that no one will be able to easily pull in upstream playdoh changes after they rename their project module. In theory that should be fine since funfactory is supposed to encapsulate it all but lately the template has been in flux. Maybe that's ok?

[peterbe]

@Kumar I like the idea of never updating playdoh again once you start. Makes playdoh a "skeleton" app (isn't it what they call rake in rails land). Thus makes playdoh-lib and funfactory do what they're supposed to do.

[davedash]

We should change the docs so we don't tell people to fork playdoh and put it in their app... then we can use master as the main branch.

[kumar303]

the more I think about this why don't we just forget about the playdoh repo and start our own variant of django-admin.py startproject? Starting a new project could be this:

mkvirtualenv my_cool_app
pip install git+git://github.com/mozilla/funfactory.git
funfactory-start my_cool_app

It would solve the app naming problem as well as some others like generating a secret key. We could even make an upgrade command that applied new changes over your directory so you can see the diff. the Paste start-app command did upgrades like this.

[tofumatt]

@kumar303 Is that a common thing to do? Extending/replacing the django-admin.py interface? If so, could we literally just make it django-admin.py startproject --playdoh or something similar?

Rails has generators that let you specify what type of libraries/types your tests (RSpec, Cucumber, etc.), templates (HTML, Haml, something else stupid), etc. should be. That'd be pretty cool.

[davedash]

@kumar303, I'd be happy to do that.

I feel like you sucked the life force out of playdoh and put it into funfactory, and now this empty shell is just an empty shell that heard you like empty shells.

[peterbe]

"sucked the life force out of playdoh and put it into funfactory," :)

it does sort of feel "wrong" that a project is based on a fork of playdoh as a repository if it's never going to update or merge back in.

I'm liking the idea of a skeleton building script you use once. However, I'd like to stay away from django-admin.py and instead just run its own funfactory script that sets up the folders and the submodules.

[fwenzel]

I do secretly hope, if "playdoh" goes away, we rename funfactory to playdoh.

That being said, I like the idea of running such a script. It would indeed simplify certain things that need to happen when first starting a playdoh project, now that playdoh itself is literally just an empty shell.

[tofumatt]

@peterbe Why would we stay away from django-admin.py? We're doing something very similar to it (arguably, the SAME thing as startproject -- we're just using a different template). Wouldn't it feel more natural to use that to start all your Django projects (especially for folks who don't always use playdoh/funfactory) that way and just specify which template you want?

@fwenzel -- We've gotta store the template somewhere. Playdoh would still need to exist, but apps using our template just wouldn't be made from git clone anymore.

[peterbe]

@tofumatt, the reason being we don't want django to be a requirement to get started. All you should need is python and pip. Also, hopefully ours will be so significantly different.

Regarding the name...
Would it be an option to start with a completely new name? funfactory and playdoh is already used for very different things actually. What about playdoh-admin?

[tofumatt]

I suppose that's a fair point about not needing Django, even though it feels incredibly weird to me. But I can't quantify why so OK.

Name? I'd say moulder, if anything. ;-)

[kumar303]

I do secretly hope, if "playdoh" goes away, we rename funfactory to playdoh.

If we make it a script then it needs to be fully available on PyPI for easier installation. Playdoh is already taken: http://pypi.python.org/pypi/playdoh

That's not the main motivator I had for splitting things off to funfactory but it was my motivation for not naming the lib playdoh-core :)

[Osmose]

That's not the main motivator I had for splitting things off to funfactory but it was my motivation for not naming the lib playdoh-core :)

I like the idea of adding the script to funfactory. Not only is the name available, but having that command could make testing funfactory easier (use the script to create a project to run tests on).

The factory part of the name also implies that it creates things. Seems fitting to me, although we lose the playdoh name. :(

[peterbe]

I haven't explored it in detail yet but in Django 1.4, new projects are created in a more pythonic fashion.
https://docs.djangoproject.com/en/dev/releases/1.4-alpha-1/#updated-default-project-layout-and-manage-py
Only manage.py is in the root directory. And the project module itself. (And a README and LICENSE.txt, etc. for completeness)

In other words, if we stop making playdoh a forkable repo and instead rely on django-admin.py startproject we'll get what we want. (yes, I believe that was tofumatt's idea)

Also, with django-admin.py startproject you can now override its template.
https://docs.djangoproject.com/en/dev/releases/1.4-alpha-1/#custom-project-and-app-templates
This could be a very interesting avenue to explore.

[davedash]

Thanks @kumar303

[kumar303]

New layout! e5b058a

documentation forthcoming