Bad assumptions with project and settings options

[sirex]

Recently I found, that projectegg was deprecated. The main reason was removal of project generation, because if projectegg was specified, project directory was not generated.

After looking at the code I found, that project option currently is used only in one place: https://github.com/rvanlaar/djangorecipe/blob/master/src/djangorecipe/recipe.py#L223

project and settings options are very limited and are based on really bad assumptions, In first place, project is expected to be a directory name under ${buildout:directory}. There are projects, where all sources are kept under src directory, some projects separate build scripts from project, and project can be installed somewhere as a Python egg.

So my suggestion would be to remove annoying project option and replace settings with dotted-settings-path. This makes djangorecipe much more flexible and much more simple:

[django]
recipe = djangorecipe
settings = project.settings.development

And you can use whatever project structure you like, without project enforcement.

[reinout]

"Enforcement", "bad", "annoying", "really bad".... May I suggest to be a little more polite when phrasing your bug reports?

And no, regarding settings there is no such assumption (I think) that project must be a directory underneath the buildout directory. It is used as part of the settings dotted path that gets passed to django. Django then tries to import it. So as long as project.settings is importable, Django doesn't mind if it is a directory underneath the buildout, a develop egg in src/ or a downloaded egg from somewhere.

The only assumption is that there currently is a check in the main code that warns you if there's no directory named after the project, suggesting that you run bin/django startproject projectname in that case. Seems reasonable to leave that in place as that's good for backwards compatibility with the previous default.

Settings are already quite flexible. I have a project lizard5 with settings settings.production and settings.development and so. They're simply concatenated. So you can have project = my_project.something, for instance.

And for corner cases where you don't have a regular main django project (where-ever you may import it from) with an importable settings (sub)module there's the dotted-settings-path option, which you can use. This is probably only necessary when you don't have your settings inside an importable python module, as far as I could see. See also https://github.com/rvanlaar/djangorecipe/issues?q=label%3Aabsolutesettingspath+is%3Aclosed . I closed those related tickets as dotted-settings-path seemed to solve it once and for all :-)

A change that might be handy is to have project to default to an empty string instead of "project", as it is now, in case dotted-settings-path is specified. The advantage is that you wouldn't get a warning about a non-existing project directory. Would that help?

[sirex]

Regarding politeness, I'm sorry, English is not my native language, and my vocabulary of English words is quite poor, so I just try to express my point of view with very limited set of words. My intentions is to make djangorecipe better, than it is now.

And no, regarding settings there is no such assumption (I think) that project must be a directory underneath the buildout directory.

Actually I don't really know what is the purpose of project. According to this

djangorecipe/src/djangorecipe/recipe.py

Lines 72 to 78 in e0d288d

	if self.options['project'] not in os.listdir(
	self.buildout['buildout']['directory']):
	# Only warn for this upon install, not on update.
	self.log.warn(
	"There's no directory named after our project. "
	"Probably you want to run 'bin/django startproject %s'",
	self.options['project'])

it should be a directory name underneath the buildout directory. Usually I read warnings and try to fix code to make them disappear.

A change that might be handy is to have project to default to an empty string instead of "project", as it is now, in case dotted-settings-path is specified. The advantage is that you wouldn't get a warning about a non-existing project directory. Would that help?

Yes, that would help.

Currently documentation says: The options below are for older projects or special cases mostly:, dotted-settings-path falls under this statement. This sounds like dotted-settings-path can be removed at any time like projectegg was.

Regarding backwards compatibility, removal of projectegg broke all my projects that use djangorecipe.

I think, project option is misleading and currently it is just an artefact left for backwards compatibility. settings is also quite confusing, it is a python path to settings module, but without project package name.

I think the right fix is to do a backwards incompatible change, like with projectegg, where project is removed and settings is replaced with dotted-settings-path.

Otherwise, removing warning about non-existing project directory would be also ok, with explanation in documentation, that dotted-settings-path = project + '.' + settings, where project is directory name under buildout root and settings is dotted settings path without project package.

Currently, just reading documentation I can't really understand what project and settings options are I could only fully understand it by reading sources.