Having a project named "code" breaks things

[anr@…]

[pequod:/tmp] $ django-admin.py startproject code
[pequod:/tmp] $ cd code
[pequod:/tmp/code] $ python manage.py runserver
Traceback (most recent call last):
  File "manage.py", line 11, in <module>
    execute_manager(settings)
  File "/usr/lib/python2.5/site-packages/django/core/management.py", line 1672, in execute_manager
    execute_from_command_line(action_mapping, argv)
  File "/usr/lib/python2.5/site-packages/django/core/management.py", line 1563, in execute_from_command_line
    from django.utils import translation
  File "/usr/lib/python2.5/site-packages/django/utils/translation/__init__.py", line 3, in <module>
    if settings.USE_I18N:
  File "/usr/lib/python2.5/site-packages/django/conf/__init__.py", line 28, in __getattr__
    self._import_settings()
  File "/usr/lib/python2.5/site-packages/django/conf/__init__.py", line 55, in _import_settings
    self._target = Settings(settings_module)
  File "/usr/lib/python2.5/site-packages/django/conf/__init__.py", line 83, in __init__
    raise EnvironmentError, "Could not import settings '%s' (Is it on sys.path? Does it have syntax errors?): %s" % (self.SETTINGS_MODULE, e)
EnvironmentError: Could not import settings 'code.settings' (Is it on sys.path? Does it have syntax errors?): No module named settings

[Simon G. <dev@…>]

@bug reporter - unfortunately this looks like a python keyword clash (and for the same reason you can't use "django" or "site" or "test"). There's not much we can do about this, and your best option is to use a different name for your project.

@core developers: This patch adds 'code' to the INVALID_PROJECT_NAMES in management.py. However, this may not be the best fix - it may be better to modify the error message instead, or include builtins in the INVALID_PROJECT_NAME check, or to do some better error checking if possible?

[anr@…]

Thanks for the comment.

I'm new to Python & Django, so I didn't take a look at the code yet.

Wouldn't it be possible to keep project names in a different namespace, so they won't interfere with reserved words?

Naive example: what about prefixing project names with "proj_" for internal use?

Regards,

--

Adriano

[Malcolm Tredinnick]

Simon: it's a never-ending arms-race to try and catch all clashes. At the end of the day, standard Python rules apply: package names must be unique. So we have to check every possible importable package name (__builtins___ is of no help there). This will be time-consuming and error-prone as well (it's not future-error-proof once you start installing third-party packages, for example).

I don't know what the right solution is, beyond asking programmers to think like Python programmers. Maybe there's something, but it's never going to be bullet-proof.

[Simon G. <dev@…>]

Yeah, that's what I thought the case would be. How about modifying the exception to make this a bit more explicit and help debug - e.g.:

raise EnvironmentError, "Could not import settings '%s' (Is it on sys.path? Does it have syntax errors? Is it clashing with an existing module called '%s'?): %s" % (self.SETTINGS_MODULE, self.SETTINGS_MODULE, e)

[Malcolm Tredinnick]

If we could work out the path the import came from, that would be useful. I'm a bit worried that your change on its own won't necessarily help somebody who gets bitten by this ("how do I check that?").

Improving the error message would be useful, I agree.

[Collin Grady <cgrady@…>]

Split the settings value on ".", import the module bit of it ([0]) direct, and check module.__file__ ?

[Simon G. <dev@…>]

#4993 was marked as a duplicate

[Simon G. <dev@…>]

#5217 is a duplicate and #3475 attempts to patch a similar issue in management.py

[Julian Bez]

so, this here seems to be a duplicate...