New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
wants to merge 1 commit into
base: base
from

Conversation

Projects
None yet
9 participants
@davedash
Member

davedash commented Sep 14, 2011

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

This comment has been minimized.

Show comment
Hide comment
@kumar303

kumar303 Sep 28, 2011

Member

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.

Member

kumar303 commented Sep 28, 2011

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

This comment has been minimized.

Show comment
Hide comment
@Osmose

Osmose Oct 1, 2011

Member

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?

Member

Osmose commented Oct 1, 2011

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

This comment has been minimized.

Show comment
Hide comment
@washort

washort Oct 1, 2011

+1, this is how python projects should look.

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

washort commented Oct 1, 2011

+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

This comment has been minimized.

Show comment
Hide comment
@Osmose

Osmose Oct 1, 2011

Member

+1 for the idea, definitely.

Member

Osmose commented Oct 1, 2011

+1 for the idea, definitely.

@erikrose

This comment has been minimized.

Show comment
Hide comment
@erikrose

erikrose Oct 1, 2011

Member

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.
Member

erikrose commented Oct 1, 2011

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

This comment has been minimized.

Show comment
Hide comment
@davedash

davedash Oct 1, 2011

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

davedash commented Oct 1, 2011

  • 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

This comment has been minimized.

Show comment
Hide comment
@robhudson

robhudson Oct 1, 2011

Member

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.

Member

robhudson commented Oct 1, 2011

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

This comment has been minimized.

Show comment
Hide comment
@tofumatt

tofumatt Oct 17, 2011

Member

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

Member

tofumatt commented Oct 17, 2011

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

This comment has been minimized.

Show comment
Hide comment
@tofumatt

tofumatt Oct 17, 2011

Member

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.

Member

tofumatt commented Oct 17, 2011

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

This comment has been minimized.

Show comment
Hide comment
@peterbe

peterbe Oct 27, 2011

Contributor

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.

Contributor

peterbe commented Oct 27, 2011

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

This comment has been minimized.

Show comment
Hide comment
@kumar303

kumar303 Oct 28, 2011

Member

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?

Member

kumar303 commented Oct 28, 2011

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

This comment has been minimized.

Show comment
Hide comment
@peterbe

peterbe Oct 28, 2011

Contributor

@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.

Contributor

peterbe commented Oct 28, 2011

@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

This comment has been minimized.

Show comment
Hide comment
@davedash

davedash Oct 28, 2011

Member

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.

Member

davedash commented Oct 28, 2011

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

This comment has been minimized.

Show comment
Hide comment
@kumar303

kumar303 Oct 29, 2011

Member

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.

Member

kumar303 commented Oct 29, 2011

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

This comment has been minimized.

Show comment
Hide comment
@tofumatt

tofumatt Oct 30, 2011

Member

@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.

Member

tofumatt commented Oct 30, 2011

@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 davedash referenced this pull request Oct 31, 2011

Closed

Stop using setup_environ() #82

@davedash

This comment has been minimized.

Show comment
Hide comment
@davedash

davedash Oct 31, 2011

Member

@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.

Member

davedash commented Oct 31, 2011

@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

This comment has been minimized.

Show comment
Hide comment
@peterbe

peterbe Oct 31, 2011

Contributor

"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.

Contributor

peterbe commented Oct 31, 2011

"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

This comment has been minimized.

Show comment
Hide comment
@fwenzel

fwenzel Oct 31, 2011

Member

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.

Member

fwenzel commented Oct 31, 2011

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

This comment has been minimized.

Show comment
Hide comment
@tofumatt

tofumatt Oct 31, 2011

Member

@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.

Member

tofumatt commented Oct 31, 2011

@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

This comment has been minimized.

Show comment
Hide comment
@peterbe

peterbe Oct 31, 2011

Contributor

@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?

Contributor

peterbe commented Oct 31, 2011

@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

This comment has been minimized.

Show comment
Hide comment
@tofumatt

tofumatt Oct 31, 2011

Member

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. ;-)

Member

tofumatt commented Oct 31, 2011

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

This comment has been minimized.

Show comment
Hide comment
@kumar303

kumar303 Oct 31, 2011

Member

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 :)

Member

kumar303 commented Oct 31, 2011

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

This comment has been minimized.

Show comment
Hide comment
@Osmose

Osmose Oct 31, 2011

Member

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. :(

Member

Osmose commented Oct 31, 2011

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

This comment has been minimized.

Show comment
Hide comment
@peterbe

peterbe Dec 28, 2011

Contributor

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.

Contributor

peterbe commented Dec 28, 2011

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

This comment has been minimized.

Show comment
Hide comment
@davedash
Member

davedash commented Jan 10, 2012

Thanks @kumar303

@davedash davedash closed this Jan 10, 2012

@kumar303

This comment has been minimized.

Show comment
Hide comment
@kumar303

kumar303 Jan 10, 2012

Member

New layout! e5b058a

documentation forthcoming

Member

kumar303 commented Jan 10, 2012

New layout! e5b058a

documentation forthcoming

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment