[Django] #22280: "Conflicting models in application" RuntimeError for same model with different paths
Django
different paths
------------------------------+--------------------
Reporter: blueyed | Owner: nobody
Type: Bug | Status: new
Component: Core (Other) | Version: master
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
------------------------------+--------------------
When I run tests using `manage.py test`, the test file
`project/app/tests.py` is used/imported with `__name__ =
"project.project.app.test"`.
When using a relative import in tests.py then, the model appears to get
registered as `project.project.app.model`.
After the database for the tests is being setup, I get the following
error:
> RuntimeError: Conflicting 'model' models in application 'app': <class
'app.models.Model'> and <class 'project.project.app.models.Model'>.
It refers to the same Model, but with different class paths.
This is triggered by / caused when using an relative import from the
tests.py file: `from .models import Model`.
I am running manage.py from the first "project" directory.
`sys.path` contains the directory `.../project/project` and not the
directory where `project.project.app` would be rooted.
With Django 1.6 the `__name__` of tests.py during the import is the same,
but there's no error, since there is no apploader that verifies uniqueness
using the labels/names.
I could not reproduce it with a simple new project/app in Django 1.7.
{{{
ERROR: project.project.app.tests (unittest.loader.ModuleImportFailure)
----------------------------------------------------------------------
ImportError: Failed to import test module: project.project.app.tests
Traceback (most recent call last):
File "/usr/lib/python2.7/unittest/loader.py", line 254, in _find_tests
module = self._get_module_from_name(name)
File "/usr/lib/python2.7/unittest/loader.py", line 232, in
_get_module_from_name
__import__(name)
File "…/project/app/tests.py", line 23, in <module>
from .views import HomePageView
File "…/project/app/views.py", line 6, in <module>
from .models import Movie, Collection
File "…/project/app/models.py", line 51, in <module>
class Person(models.Model):
File "…/django-master/django/db/models/base.py", line 299, in __new__
new_class._meta.apps.register_model(new_class._meta.app_label,
new_class)
File "…/django-master/django/apps/registry.py", line 201, in
register_model
(model_name, app_label, app_models[model_name], model))
RuntimeError: Conflicting 'person' models in application 'app': <class
'app.models.Person'> and <class 'project.project.app.models.Person'>.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/22280>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
different paths
Reporter: blueyed | Owner: nobody
Type: Bug | Status: new
Component: Core (Other) | Version: master
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by blueyed):
* needs_better_patch: => 0
* needs_tests: => 0
* needs_docs: => 0
Comment:
I had initially reported it for pytest_django:
https://github.com/pelme/pytest_django/issues/75
There is more information available (e.g. the full output from ipdb's
`where`).
--
Ticket URL: <https://code.djangoproject.com/ticket/22280#comment:1>
Django
different paths
Reporter: blueyed | Owner: nobody
Type: Bug | Status: new
Component: Core (Other) | Version: master
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by blueyed):
The different paths were caused by an `__init__.py` file in the root
directory.
--
Ticket URL: <https://code.djangoproject.com/ticket/22280#comment:2>
Django
different paths
Reporter: blueyed | Owner: nobody
Type: Bug | Status: new
Component: Core (Other) | Version: master
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by blueyed):
But with `project/project/__init__.py` (the default startproject layout),
the error from Django persists, but the "previous" model gets recognized
as `project.app.models.Model`.
--
Ticket URL: <https://code.djangoproject.com/ticket/22280#comment:3>
Django
different paths
Reporter: blueyed | Owner: nobody
Type: Bug | Status: new
Component: Core (Other) | Version: master
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by aaugustin):
The same model gets imported through two different paths. That used to be
possible, but it's forbidden in Django 1.7.
Django 1.6 and earlier used some rather dark magic to return the same
object instead of a copy, which is what Python does when you import a
module through different paths.
With the information you've provided, I'm not exactly sure why you end up
in this situation, and nothing points to a bug in Django.
Inserting `import sys; print(sys.path)` just before the point where Django
raises an error may help. You could also inspect the content of the app
registry (`from django.apps import apps`) at that point.
--
Ticket URL: <https://code.djangoproject.com/ticket/22280#comment:4>
Django
different paths
Reporter: blueyed | Owner: nobody
Type: Bug | Status: closed
Component: Core (Other) | Version: master
Keywords: app-loading | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by aaugustin):
* status: new => closed
* keywords: => app-loading
* resolution: => needsinfo
--
Ticket URL: <https://code.djangoproject.com/ticket/22280#comment:5>
Django
different paths
Reporter: blueyed | Owner: nobody
Type: Bug | Status: closed
Component: Core (Other) | Version: master
Keywords: app-loading | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by blueyed):
Thanks for your help!
I think I figured it out (at least a bit more): because of the __init__.py
files above the app (in the project dir), the relative import uses the
whole package name ("project.app").
Django maybe manages it to get the __name__ setup without using the whole
of the package name.
For now, I have removed the __init__.py files from the project dir (and
above), so each app is considered to be a separate package.
Regarding the app-loading behavior: if Django would also use the whole
package name for the import (which appears to get shortened?!) or would
track it for later comparison, that might help here.
(Please note that I might have overseen some `__init__.pyc` while removing
`__init__.py` files before)
--
Ticket URL: <https://code.djangoproject.com/ticket/22280#comment:6>
Django
different paths
Reporter: blueyed | Owner: nobody
Type: Bug | Status: closed
Component: Core (Other) | Version: master
Keywords: app-loading | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by aaugustin):
Here's my theory:
- The current working directory is automatically added to PYTHONPATH.
- You're doing `import app.foo.bar` somewhere.
This starts an import from your working directory, which is inside the
projet root directory.
--
Ticket URL: <https://code.djangoproject.com/ticket/22280#comment:7>
Django
different paths
Reporter: blueyed | Owner: nobody
Type: Bug | Status: closed
Component: Core (Other) | Version: master
Keywords: app-loading | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by blueyed):
> The current working directory is automatically added to PYTHONPATH.
That does not appear to make a difference, since I tried it with from
different directories.
> You're doing import app.foo.bar somewhere.
That does not appear to be the case.
From my understanding, a relative import will just use the full package
name always.
In `register_model` it looks like follows: via the relative import
(project/project/app/tests.py):
> ('register_model', u'app', <class 'project.app.models.Person'>)
And the later model appears as:
> ('register_model', 'app', <class '__fake__.Person'>)
This gets done via `ModelState.render`.
When using `runserver` instead of `tests`, the model appears as:
> ('register_model', 'app', <class 'app.models.Person'>)
It gets setup via django/apps/config.py / `import_module` / INSTALLED_APPS
then.
--
Ticket URL: <https://code.djangoproject.com/ticket/22280#comment:8>
Django
different paths
Reporter: blueyed | Owner: nobody
Type: Bug | Status: closed
Component: Core (Other) | Version: master
Keywords: app-loading | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by aaugustin):
I suspect `__fake__.Person` is just a misdirection caused by the
migrations framework.
You're seeing alternatively `project.app.models.Person` and
`app.models.Person`. AFAICT that means that both `project` and
`project/project` are on PYTHONPATH. Could you print `sys.path` in
`register_model` and report the results?
--
Ticket URL: <https://code.djangoproject.com/ticket/22280#comment:9>
Django
different paths
Reporter: blueyed | Owner: nobody
Type: Bug | Status: closed
Component: Core (Other) | Version: master
Keywords: app-loading | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by blueyed):
Yes, both `project` and `project/project` are in sys.path:
`sys.path` looks as follows when the exception gets raised (and also
before the relative imports):
'/project'
'/project/virtualenv/src/autocomplete-light'
'/project/project'
'/project/virtualenv/src/django-grappelli'
...
But also with only `project/project` on sys.path (depending on the package
/ __init__.py layout), the problem persists: it's just different then how
the conflicting model is named.
> I suspect __fake__.Person is just a misdirection caused by the
migrations framework.
Does this mean, it should not show up as "__fake__." here?
--
Ticket URL: <https://code.djangoproject.com/ticket/22280#comment:10>
Django
different paths
Reporter: blueyed | Owner: nobody
Type: Bug | Status: closed
Component: Core (Other) | Version: master
Keywords: app-loading | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by aaugustin):
Having a directory and a subdirectory is PYTHONPATH isn't supported any
more. See the third paragraph in the release notes:
https://docs.djangoproject.com/en/dev/releases/1.7/#app-registry-
consistency. You must be setting PYTHONPATH explicity to end up in this
situation. Since you're using relative imports, you should be able to
remove this customization. Maybe you'll have to fix a few imports.
Once you've fixed that, if you're still encountering issues with
`__fake__.Person`, could you reopen the ticket? By "misdirection" I meant
that it was either irrelevant to the first problem or a totally different
problem.
Thanks for bearing with me while we debug this!
--
Ticket URL: <https://code.djangoproject.com/ticket/22280#comment:11>
Django
different paths
Reporter: blueyed | Owner: nobody
Type: Bug | Status: new
Component: Core (Other) | Version: master
Keywords: app-loading | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by blueyed):
* status: closed => new
* resolution: needsinfo =>
Comment:
> Having a directory and a subdirectory is PYTHONPATH isn't supported any
more.
Let me quote myself:
>> But also with only project/project on sys.path (depending on the
package / init.py layout), the problem persists
> You must be setting PYTHONPATH explicity to end up in this situation.
No. It's just that I have `pip install -e .`ed the project directory, and
then it depends on the __init__.py files layout.
I am not setting PYTHONPATH explicitly somewhere (I have checked
virtualenvwrapper and envdir).
> Since you're using relative imports, you should be able to remove this
customization. Maybe you'll have to fix a few imports.
The workaround is clear: using non-relative imports (when using the Django
or py.test testrunner), or removing the __init__.py file from the root
directory - if I recall/remember it correctly.
It's just a bit inconvenient having to use the app name in the app itself
for imports in the tests.
Using relative imports in the app's views.py is fine.
> Thanks for bearing with me while we debug this!
I thank you for your help and support - and still hope that I am not just
doing something stupid.. ;)
(FWIW, I am now getting the following error with `manage.py test` (but not
with py.test) - `django` being a symlink to `django-master`:
> ImportError: 'test_http' module incorrectly imported from '…/django-
master/django/contrib/sitemaps/tests'. Expected
'…/django/contrib/sitemaps/tests'. Is this module globally installed?
That one is coming from `/usr/lib/python2.7/unittest/loader.py` though,
and just popped up when I've tried to look for the current state of
`__fake__.Person` models).
'''Let me once repeat, to make it clear, I think that the main issue is
that a relative import causes Python to use the whole package name for the
module, but the imports through Django somehow only use the app's path
relative to the main project path (with the project prefix being
removed).'''
--
Ticket URL: <https://code.djangoproject.com/ticket/22280#comment:12>
Django
different paths
Reporter: blueyed | Owner: nobody
Type: Bug | Status: new
Component: Core (Other) | Version: master
Keywords: app-loading | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by aaugustin):
First, a question: are you using explicit relative imports (`from .xxx
import ...`) or implicit relative imports (`from xxx import ...`)? If
you're using the latter form, you might be accidentally using absolute
imports.
Let me explain a bit.
Assume the following structure:
{{{
root/
root/__init__.py
root/foo/
root/foo/__init__.py
root/foo/bar.py
root/foo/baz.py
}}}
Assume both `root` and `foo` are on `PYTHONPATH` (bear with me for a
moment).
Assume `foo/__init__.py` contains `import bar` and that line is executing.
Assume `foo/bar.py` contains `from baz import ...`. Then an absolute
import will be performed, since `baz.py` is found in `foo` which is on
`PYTHONPATH`, and the `baz` module is registered as `'baz'` in
`sys.modules`.
On the other hand, if foo/bar.py contains `from .baz import ...`, then a
relative import will be performed, and the `baz` module is registered as
`'foo.baz'` in `sys.modules`.
This bears some resemblance with the symptoms you're describing and
doesn't involve dark magic in Django. (There used to be some dark magic in
this area, but we removed it in 1.4.)
----
Now, regarding your particular situation, `pip install -e .` has the
effect of adding `.` -- the current directory at the moment you're issuing
the command -- to `PYTHONPATH`. There's a variety of way to set
`PYTHONPATH` and that's why I was insisting on printing `sys.path`.
Considering your project layout, I believe only the "outer" `project`
folder -- the one that contains manage.py -- should be on `PYTHONPATH`.
If I read you correctly, the "inner" `project` folder -- the one next to
manage.py -- is also on `PYTHONPATH` because you added it with `pip
install -e`. When you're executing management commands, such as running
the tests, with `manage.py`, Python automatically adds the folder
containing manage.py -- the "outer" `project` folder -- to `PYTHONPATH`.
That's one way you can end up with the two `project` folders on
`PYTHONPATH` and suffer from the ambiguity between absolute imports and
implicit relative imports I described above. The answer is to always use
explicit relative imports. Implicit relative imports are a footgun.
----
Finally, your analysis in bold is inconsistent with what I know about
Django. Attaching a minimal sample project with reproduction instructions
would help me, or someone else, figure out what's going on.
--
Ticket URL: <https://code.djangoproject.com/ticket/22280#comment:13>
Django
different paths
Reporter: blueyed | Owner: nobody
Type: Bug | Status: closed
Component: Core (Other) | Version: master
Keywords: app-loading | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by aaugustin):
* status: new => closed
* resolution: => needsinfo
Comment:
Closing again, because I don't think there's a bug in Django. I will to
investigate more if you can provide a minimal project exhibiting this
issue. Thank you!
--
Ticket URL: <https://code.djangoproject.com/ticket/22280#comment:14>
Django
different paths
Reporter: blueyed | Owner: nobody
Type: Bug | Status: new
Component: Core (Other) | Version: master
Keywords: app-loading | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by blueyed):
* status: closed => new
* resolution: needsinfo =>
Comment:
I have investigated a bit more, and it appears that the main problem is
having
an `__init__.py` file next to `manage.py`, which causes the testrunner /
unittest to add its directory to sys.path.
Please note that this issue appears to be related to running tests via
`manage.py test` only!
From the [https://docs.djangoproject.com/en/dev/releases/1.7/#app-
registry-consistency 1.7 release notes]:
> It isn’t possible to import the same model twice through different paths
any more.
Fair enough, and that's basically what this issue is about - so it would
just
not be supported anymore.
However, the release note also state:
> As of Django 1.6, this may happen only if you’re manually putting a
directory
> and a subdirectory on PYTHONPATH. Refer to the section on the new
project
> layout in the 1.4 release notes for migration instructions.
Since I am not manually changing PYTHONPATH it appears to be an issue with
Django's testrunner.
I have create a test repo for this issue:
https://github.com/blueyed/test-django-issue-22280
Let me elaborate how to reproduce it:
As for a sample test project, just create a new one using "startproject"
and
"startapp", and then add an additional `__init__.py` next to `manage.py`:
{{{
project
├── app
│ ├── admin.py
│ ├── __init__.py
│ ├── models.py
│ ├── tests.py
│ └── views.py
├── __init__.py (added additionally)
├── manage.py
└── project
├── __init__.py
├── settings.py
├── urls.py
└── wsgi.py
}}}
Running the tests will fail:
{{{
ERROR: project.app.tests (unittest.loader.ModuleImportFailure)
----------------------------------------------------------------------
ImportError: Failed to import test module: project.app.tests
[...]
ImportError: No module named app.tests
}}}
That's understandable, because now there's `../project` and
`../project/project` on sys.path, which is ambiguous.
Let's rename the top-level `project` folder to `proot`.
`manage.py test` runs fine now.
But when you then use both `from app.models import Model` (in your
project,
e.g. via `manage.py`) and `from .models import Model` in the tests, it
will
result in the error:
{{{
======================================================================
ERROR: proot.app.tests (unittest.loader.ModuleImportFailure)
----------------------------------------------------------------------
ImportError: Failed to import test module: proot.app.tests
Traceback (most recent call last):
File "/usr/lib/python2.7/unittest/loader.py", line 257, in _find_tests
module = self._get_module_from_name(name)
File "/usr/lib/python2.7/unittest/loader.py", line 235, in
_get_module_from_name
__import__(name)
File "/tmp/djt/proot/app/tests.py", line 3, in <module>
from .models import Model
File "/tmp/djt/proot/app/models.py", line 3, in <module>
class Model(models.Model):
File "/tmp/djt/venv/local/lib/python2.7/site-
packages/django/db/models/base.py", line 286, in __new__
new_class._meta.apps.register_model(new_class._meta.app_label,
new_class)
File "/tmp/djt/venv/local/lib/python2.7/site-
packages/django/apps/registry.py", line 201, in register_model
(model_name, app_label, app_models[model_name], model))
RuntimeError: Conflicting 'model' models in application 'app': <class
'app.models.Model'> and <class 'proot.app.models.Model'>.
}}}
I've been running into this, because my project layout is basically
everything
from `project/project` moved to `project`.
{{{
DJANGO_SETTINGS_MODULE=settings
project
├── app
│ ├── admin.py
│ ├── __init__.py
│ ├── models.py
│ ├── tests.py
│ └── views.py
├── __init__.py
├── manage.py
├── settings.py
├── urls.py
└── wsgi.py
}}}
As a side-note, the [https://docs.djangoproject.com/en/dev/releases/1.4
/#updated-default-project-layout-and-manage-py release notes for 1.4 about
the new project layout], which are references from the 1.7 release notes,
mention:
> If settings, URLconfs and apps within the project are imported or
referenced
> using the project name prefix (e.g. myproject.settings, ROOT_URLCONF =
> "myproject.urls", etc), the new manage.py will need to be moved one
directory
> up, so it is outside the project package rather than adjacent to
settings.py
> and urls.py.
This implies that it's supported to have them available without the
project
name prefix?!
But in the end the whole issue appears to be with `unittest` / Django's
testrunner/unittest only, which manipulates `sys.path` when there is an
`__init__.py` next to manage.py.
I've tested it now with both master and 1.7.x.
--
Ticket URL: <https://code.djangoproject.com/ticket/22280#comment:15>
Django
different paths
Reporter: blueyed | Owner: nobody
Type: Bug | Status: new
Component: Core (Other) | Version: master
Keywords: app-loading | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by aaugustin):
Your examples look like the directory containing the outer "project" or
"proot" directory in on PYTHONPATH.
I'm saying this because you have module names like `project.app.tests` and
`proot.app.tests` in your examples.
Can you confirm?
There's no good reason for that. Only "projet" or "proot" should be on
PYTHONPATH.
The `__init__.py` is a red herring. It just makes the error more
confusing.
--
Ticket URL: <https://code.djangoproject.com/ticket/22280#comment:16>
Django
different paths
Reporter: blueyed | Owner: nobody
Type: Bug | Status: new
Component: Core (Other) | Version: master
Keywords: app-loading | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by blueyed):
> Your examples look like the directory containing the outer "project" or
"proot" directory is on PYTHONPATH.
No. This is a new shell, and I have created the virtualenv with
`virtualenv venv` explicitly.
> The __init__.py is a red herring. It just makes the error more
confusing.
No, with __init__.py the tests fail, and removing it make them run -
because then `/tmp/test-django-issue-22280` gets not added to sys.path and
the model/app gets not imported with different paths.
I have added a Makefile to the test repo. You should be able to reproduce
it with:
{{{
1. git clone https://github.com/blueyed/test-django-issue-22280
2. cd test-django-issue-22280
3. make test
}}}
It uses the `1.7c1` tarball. You may want to use a local checkout instead.
--
Ticket URL: <https://code.djangoproject.com/ticket/22280#comment:17>
Django
different paths
Reporter: blueyed | Owner: nobody
Type: Bug | Status: new
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by aaugustin):
* keywords: app-loading =>
* component: Core (Other) => Testing framework
* stage: Unreviewed => Accepted
Comment:
Thanks for the example project. I ran it and reproduced the error:
{{{
RuntimeError: Conflicting 'model' models in application 'app': <class
'app.models.Model'> and <class 'proot.app.models.Model'>.
}}}
It's pretty clear in this error that the same `Model` class was imported
through two different Python paths: `app.models` and `proot.app.models`.
That is always an error and it's purposefully forbidden in Django 1.7.
However, the reasons why this happens aren't obvious.
If you aren't convinced that it's always an error, learn about [http
://python-
notes.curiousefficiency.org/en/latest/python_concepts/import_traps.html
#the-double-import-trap the double import trap] and come back.
With `python -Wall` I got this warning:
{{{
test-django-issue-22280/proot/app/models.py:3: RemovedInDjango19Warning:
Model class app.models.Model doesn't declare an explicit app_label and
either isn't in an application in INSTALLED_APPS or else was imported
before its application was loaded. This will no longer be supported in
Django 1.9.
}}}
It's referring to `app.models.Model` which is the expected path. So I went
ahead and added `'app'` to `INSTALLED_APPS`.
Then I got this warning:
{{{
test-django-issue-22280/proot/app/models.py:3: RemovedInDjango19Warning:
Model class proot.app.models.Model doesn't declare an explicit app_label
and either isn't in an application in INSTALLED_APPS or else was imported
before its application was loaded. This will no longer be supported in
Django 1.9.
}}}
Note that it's referring to `proot.app.models.Model` now which is
unexpected.
To debug this further, I added `from pprint import pprint; import sys;
pprint(sys.path)` in `app/models.py`.
As expected, that shows that the module is imported twice. The first time,
`sys.path` contains `test-django-issue-22280/proot`, and then venv and
system stuff. The second time, it contains `test-django-issue-22280`,
`test-django-issue-22280/proot`, and the same venv and system stuff.
That's where the `__init__.py` begins to make a difference. Once `test-
django-issue-22280` is added to `sys.path`, the `__init__.py` makes in
possible to import Python objects as `proot.xxx`, and the double import
trap appears.
So the question becomes -- what added `test-django-issue-22280` on
`sys.path`? I think it happens somewhere in `DiscoverRunner.build_suite`.
I don't understand that code very well.
I'm going to stop there for now because I don't think it's an app-loading
regression. App-loading just raised an error, as intended, in one of the
situations it was designed to prevent.
Considering that you're the only person to have complained about this, and
that your example contains fairly weird stuff, I'm not marking this as a
release blocker. For example, why on Earth would you import a model in
`manage.py`? I don't think it's relevant here, but seriously, I wasted a
lot of time just to find that out...
--
Ticket URL: <https://code.djangoproject.com/ticket/22280#comment:18>
Django
different paths
Reporter: blueyed | Owner: nobody
Type: Bug | Status: new
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by blueyed):
Thanks for your time, investigation and explanations.
Just to clarify:
> For example, why on Earth would you import a model in `manage.py`? I
don't think it's relevant here, but seriously, I wasted a lot of time just
to find that out...
Sorry, that was meant to simulate loading it early, similar to how e.g.
autocomplete_light's discovery (might) work(s), and I've thought it would
be necessary to trigger it.
But just having it in INSTALLED_APPS (and removing it from manage.py) also
triggers this issue. I have updated the test project accordingly, which is
now only weird in the regard that it has a `__init__.py` next to
manage.py.
--
Ticket URL: <https://code.djangoproject.com/ticket/22280#comment:19>
Django
different paths
Reporter: blueyed | Owner: nobody
Type: Bug | Status: new
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by carljm):
This is due to
https://github.com/django/django/blob/master/django/test/runner.py#L71 and
following, which is admittedly ugly (see the comment), but I'm also not
sure that we have a better option.
Unittest has a concept of a "top-level dir" which it will place on
`sys.path` and import things relative to. You can specify this explicitly
(and we provide a way to do that via `manage.py test` with the `-t`
option). If you don't, unittest's default is to set the top-level dir to
be the immediate containing directory of the test file being run.
Unittest's default choice is usually wrong (for any test file that is not
actually a top-level module; and most Django test files are not, because
they tend to be within apps) and we did not want to require everyone to
specify the `-t` option explicitly all the time. So we walk up the
directory tree looking for `__init__.py` files and consider the top-level
dir to be the first dir we find that doesn't have one. This is usually
correct, if there are `__init__.py` files where there should be and none
where there shouldn't be. The OP here has an `__init__.py` file where
there should not be one, thus our auto-detection of the top-level dir
breaks.
Another problem with our best-effort approach here is that PEP 420 allows
Python packages without `__init__.py` files; as usage of versions of
Python including PEP 420 support (3.3+, I think?) increases and people
start leaving out `__init__.py` files in their projects, I expect we will
see more reports of our top-level-detection code breaking.
It would be nice if unittest had an option to say "assume `sys.path` is
already set up correctly and don't add anything to it", since in a normal
Django project structure the location of `manage.py` already adds the
correct top-level dir to `sys.path` anyway, but AFAIK unittest has no such
option. If you pass it a dotted module path instead of a file path, it
doesn't add anything to `sys.path` - but unfortunately as noted in our
code comment, given a single top-level module name unittest chooses to
treat it as "file path" rather than "dotted module path" and go ahead and
make the `sys.path` addition (and then by default it adds the given
directory, rather than its containing directory, to `sys.path`). So we
need to pass it a correct top-level directory, and this `__init__.py`
search is our best effort to do so.
We could request changes to unittest's API to help us here; those changes
wouldn't actually help us for quite some time, though, given that we are
tied to supporting the version of unittest in the Python 2.7 stdlib, which
won't include any such changes.
So given the unittest API limitations we are working within, here are the
options I can see for improvement:
1. We could just add better documentation of what our test runner does,
and the implication that you need to have `__init__.py` files located
within all your Python packages, but not in directories that are not
Python packages (i.e. the directory containing `manage.py`).
2. We could detect by looking for `manage.py` instead of looking for
`__init__.py` files. I include this for completeness, but it is a bad
solution. It would break when running tests for apps outside a "Django
project", it would break for any project that doesn't use `manage.py` or
has renamed it (both perfectly valid things to do), etc.
3. We could try detecting the top-level dir by walking up the filesystem
and checking each directory to see if it is already on `sys.path`, and
assuming it is the top-level dir if it is. I _think_ this should work at
least as correctly as the current approach, but would need to play with it
to be sure it handles various edge cases properly (running tests in out-
of-project apps, etc). It should fix the OP's scenario. Choosing this
approach would mean that you can only run Django tests if you've already
set up `sys.path` - this should be fine for people using `manage.py test`,
but it could break some unusual approaches used by some projects that
currently rely on unittest's `sys.path` additions; so it would have to be
considered a potentially backwards-incompatible change.
4. As a variant of (3), we could try to minimize the backwards-
incompatibility by first looking for "directory already on `sys.path`",
and if we walk up to the fs root and haven't found one, we could fall back
to the current `__init__.py` finding.
I don't expect to write a patch for this in the near future, but as the
person responsible for that code I will commit to reviewing (and possibly
committing) any patches that may be proposed.
--
Ticket URL: <https://code.djangoproject.com/ticket/22280#comment:20>
Django
different paths
Reporter: blueyed | Owner: nobody
Type: Bug | Status: new
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by MalikRumi):
1. Thanks to all of you for your detailed and ongoing comments which
helped me understand what is going on.
2. Blueyed, you are no longer the only one having this issue. I'm not sure
that's good news.
3. There are some significant differences in our experiences, however:
a) I am still pretty new to both Python and Django, so my analytical
prowess is not as developed as the rest of you. I may be over reporting
irrelevant information and under reporting the relevant.
b) I am on a Windows 8.1 machine with Python 2.7 and Django 1.7c1.
c) I have not run any tests whatsoever. This all started when I ran
makemigrations for the first time. I got a whole series of errors, and
shifted to python manage.py shell, where the errors still came up. I was
working through them one by one until I got to this one:
{{{ File "G:\Jasmine\Sydney\lib\site-packages\django\apps\registry.py",
line 201, in register_model (model_name, app_label,
app_models[model_name], model))
RuntimeError: Conflicting 'articles' models in application 'usconst':
<class 'apps.usconst.models.Articles'> and <class
'Baillee.apps.usconst.models.Articles'>.}}}
After reading this ticket, I remembered adding my G: drive to Pythonpath.
I can't recall now why I did that, but it must have been as a result of an
earlier error and trying to cover all bases. So I removed that, restarted
the machine, ran the shell, fully expecting that to resolve my isssue...
and got the same error.
I do not have {{{__init.py}}} next to manage.py.
I installed everything with pip. I did not use .e or any other flags.
My imports, admin.py. & views.py, are from .models.
I'm not sure what else you need to know. I look forward to helping
expedite a resolution.
--
Ticket URL: <https://code.djangoproject.com/ticket/22280#comment:21>
Django
different paths
Reporter: blueyed | Owner: nobody
Type: Bug | Status: new
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by collinanderson):
What is your ROOT_URLCONF set to and how are you referencing your views in
your urls.py? How are you referencing your apps in INSTALLED_APPS? Does
manage.py live in Baillee or next to Baillee?
--
Ticket URL: <https://code.djangoproject.com/ticket/22280#comment:22>
Django
different paths
Reporter: blueyed | Owner: nobody
Type: Bug | Status: new
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by MalikRumi):
ROOT_URLCONF = '%s.urls' % SITE_NAME
SITE_NAME = basename(DJANGO_ROOT)
DJANGO_ROOT = dirname(dirname(abspath(__file__)))
url(r'^usconst/', include('usconst.urls')), [this is
g:\Jasmine\Baillee\Baillee\urls.py]
urlpatterns = patterns('',
url(r'^usconst/$',
apps.usconst.views.catland(template_name='statute.html')),
url(r'^usconst/Article\s\d[1-5]|[I-V]',
apps.usconst.views.TOC(template_name='statute.html')),
url(r'^usconst/Article\s\d[1-5]\s\Section\d[1-5]',
apps.usconst.views.sectionView(template_name='statute.html')),
url(r'^usconst/(?P<slug>)',
apps.usconst.views.sectionView(template_name='statute.html')),
[this is G:\Jasmine\Baillee\Baillee\apps\usconst\urls.py - I noticed a
missing ' in the regex and fixed it but still got the conflicting names
error]
LOCAL_APPS = (
'apps.usconst.apps.UsconstConfig',
INSTALLED_APPS = DJANGO_APPS + THIRD_PARTY_APPS + LOCAL_APPS
G:\Jasmine\Baillee\manage.py
--
Ticket URL: <https://code.djangoproject.com/ticket/22280#comment:23>
Django
different paths
Reporter: blueyed | Owner: nobody
Type: Bug | Status: new
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by collinanderson):
* cc: cmawebsite@… (added)
Comment:
You either need to move your `apps` folder next `manage.py` or reference
things as `Baillee.apps.usconst` instead of `apps.usconst`. Always
reference absolute import paths relative to manage.py
--
Ticket URL: <https://code.djangoproject.com/ticket/22280#comment:24>
Django
different paths
Reporter: blueyed | Owner: nobody
Type: Bug | Status: new
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by MalikRumi):
Replying to [comment:24 collinanderson]:
> You either need to move your `apps` folder next `manage.py` or reference
things as `Baillee.apps.usconst` instead of `apps.usconst`. Always
reference absolute import paths relative to manage.py
-
I chose to go to absolute paths instead of moving apps, and that cleared
up the conflict problem, so thanks. However, now I am getting a NameError
- 'Baillee' is not defined - in my usconst/urls.py, which is importing *
from views which in turn imports from models. I changed the * to specify
the views but that made no difference. My understanding is that this error
comes up because it is the first time Django/Python has seen a term and
does not know what it is/means/represents. But if the checks are run in
models and views before urls, why is this happening? I know this is not
supposed to be a support forum, but I've been looking since yesterday with
no luck. Any suggestions?
--
Ticket URL: <https://code.djangoproject.com/ticket/22280#comment:25>
Django
different paths
-----------------------------------+------------------------------------
Reporter: blueyed | Owner: nobody
Type: Bug | Status: new
Component: Testing framework | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-----------------------------------+------------------------------------
Comment (by collinanderson):
Would you be willing to post a traceback?
--
Ticket URL: <https://code.djangoproject.com/ticket/22280#comment:26>
Django
different paths
-----------------------------------+------------------------------------
Reporter: blueyed | Owner: nobody
Type: Bug | Status: new
Component: Testing framework | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-----------------------------------+------------------------------------
Comment (by MalikRumi):
Replying to [comment:26 collinanderson]:
> Would you be willing to post a traceback?
I'd be willing to do just about anything... thx.
{{{
<> Note the typo 'shall' instead of 'shell' makes no difference -
(Sydney) G:\Jasmine\Baillee>python manage.py shall
Traceback (most recent call last):
File "manage.py", line 10, in <module>
execute_from_command_line(sys.argv)
File "G:\Jasmine\Sydney\lib\site-
packages\django\core\management\__init__.py",
line 385, in execute_from_command_line
utility.execute()
File "G:\Jasmine\Sydney\lib\site-
packages\django\core\management\__init__.py",
line 354, in execute
django.setup()
File "G:\Jasmine\Sydney\lib\site-packages\django\__init__.py", line 21,
in set
up
apps.populate(settings.INSTALLED_APPS)
File "G:\Jasmine\Sydney\lib\site-packages\django\apps\registry.py", line
112,
in populate
app_config.ready()
File "G:\Jasmine\Sydney\lib\site-packages\debug_toolbar\apps.py", line
15, in
ready
dt_settings.patch_all()
File "G:\Jasmine\Sydney\lib\site-packages\debug_toolbar\settings.py",
line 215
, in patch_all
patch_root_urlconf()
File "G:\Jasmine\Sydney\lib\site-packages\debug_toolbar\settings.py",
line 203
, in patch_root_urlconf
reverse('djdt:render_panel')
File "G:\Jasmine\Sydney\lib\site-packages\django\core\urlresolvers.py",
line 5
13, in reverse
app_list = resolver.app_dict[ns]
File "G:\Jasmine\Sydney\lib\site-packages\django\core\urlresolvers.py",
line 3
29, in app_dict
self._populate()
File "G:\Jasmine\Sydney\lib\site-packages\django\core\urlresolvers.py",
line 2
69, in _populate
for pattern in reversed(self.url_patterns):
File "G:\Jasmine\Sydney\lib\site-packages\django\core\urlresolvers.py",
line 3
67, in url_patterns
patterns = getattr(self.urlconf_module, "urlpatterns",
self.urlconf_module)
File "G:\Jasmine\Sydney\lib\site-packages\django\core\urlresolvers.py",
line 3
61, in urlconf_module
self._urlconf_module = import_module(self.urlconf_name)
File "C:\Python27\Lib\importlib\__init__.py", line 37, in import_module
__import__(name)
File "G:\Jasmine\Baillee\Baillee\urls.py", line 25, in <module>
url(r'^usconst/', include('Baillee.apps.usconst.urls')),
File "G:\Jasmine\Sydney\lib\site-packages\django\conf\urls\__init__.py",
line
28, in include
urlconf_module = import_module(urlconf_module)
File "C:\Python27\Lib\importlib\__init__.py", line 37, in import_module
__import__(name)
File "G:\Jasmine\Baillee\Baillee\apps\usconst\urls.py", line 6, in
<module>
url(r'^usconst/$',
Baillee.apps.usconst.views.catland(template_name='statute
.html')),
NameError: name 'Baillee' is not defined
<>
Typo corrected -
(Sydney) G:\Jasmine\Baillee>python manage.py shell
Traceback (most recent call last):
File "manage.py", line 10, in <module>
execute_from_command_line(sys.argv)
File "G:\Jasmine\Sydney\lib\site-
packages\django\core\management\__init__.py",
line 385, in execute_from_command_line
utility.execute()
File "G:\Jasmine\Sydney\lib\site-
packages\django\core\management\__init__.py",
line 354, in execute
django.setup()
File "G:\Jasmine\Sydney\lib\site-packages\django\__init__.py", line 21,
in set
up
apps.populate(settings.INSTALLED_APPS)
File "G:\Jasmine\Sydney\lib\site-packages\django\apps\registry.py", line
112,
in populate
app_config.ready()
File "G:\Jasmine\Sydney\lib\site-packages\debug_toolbar\apps.py", line
15, in
ready
dt_settings.patch_all()
File "G:\Jasmine\Sydney\lib\site-packages\debug_toolbar\settings.py",
line 215
, in patch_all
patch_root_urlconf()
File "G:\Jasmine\Sydney\lib\site-packages\debug_toolbar\settings.py",
line 203
, in patch_root_urlconf
reverse('djdt:render_panel')
File "G:\Jasmine\Sydney\lib\site-packages\django\core\urlresolvers.py",
line 5
13, in reverse
app_list = resolver.app_dict[ns]
File "G:\Jasmine\Sydney\lib\site-packages\django\core\urlresolvers.py",
line 3
29, in app_dict
self._populate()
File "G:\Jasmine\Sydney\lib\site-packages\django\core\urlresolvers.py",
line 2
69, in _populate
for pattern in reversed(self.url_patterns):
File "G:\Jasmine\Sydney\lib\site-packages\django\core\urlresolvers.py",
line 3
67, in url_patterns
patterns = getattr(self.urlconf_module, "urlpatterns",
self.urlconf_module)
File "G:\Jasmine\Sydney\lib\site-packages\django\core\urlresolvers.py",
line 3
61, in urlconf_module
self._urlconf_module = import_module(self.urlconf_name)
File "C:\Python27\Lib\importlib\__init__.py", line 37, in import_module
__import__(name)
File "G:\Jasmine\Baillee\Baillee\urls.py", line 25, in <module>
url(r'^usconst/', include('Baillee.apps.usconst.urls')),
File "G:\Jasmine\Sydney\lib\site-packages\django\conf\urls\__init__.py",
line
28, in include
urlconf_module = import_module(urlconf_module)
File "C:\Python27\Lib\importlib\__init__.py", line 37, in import_module
__import__(name)
File "G:\Jasmine\Baillee\Baillee\apps\usconst\urls.py", line 6, in
<module>
url(r'^usconst/$',
Baillee.apps.usconst.views.catland(template_name='statute
.html')),
NameError: name 'Baillee' is not defined
<>
This is with 'Baillee.apps.usconst.views' commented out of the import line
in usconst/urls.py -
(Sydney) G:\Jasmine\Baillee>python manage.py shell
Traceback (most recent call last):
File "manage.py", line 10, in <module>
execute_from_command_line(sys.argv)
File "G:\Jasmine\Sydney\lib\site-
packages\django\core\management\__init__.py",
line 385, in execute_from_command_line
utility.execute()
File "G:\Jasmine\Sydney\lib\site-
packages\django\core\management\__init__.py",
line 354, in execute
django.setup()
File "G:\Jasmine\Sydney\lib\site-packages\django\__init__.py", line 21,
in set
up
apps.populate(settings.INSTALLED_APPS)
File "G:\Jasmine\Sydney\lib\site-packages\django\apps\registry.py", line
112,
in populate
app_config.ready()
File "G:\Jasmine\Sydney\lib\site-packages\debug_toolbar\apps.py", line
15, in
ready
dt_settings.patch_all()
File "G:\Jasmine\Sydney\lib\site-packages\debug_toolbar\settings.py",
line 215
, in patch_all
patch_root_urlconf()
File "G:\Jasmine\Sydney\lib\site-packages\debug_toolbar\settings.py",
line 203
, in patch_root_urlconf
reverse('djdt:render_panel')
File "G:\Jasmine\Sydney\lib\site-packages\django\core\urlresolvers.py",
line 5
13, in reverse
app_list = resolver.app_dict[ns]
File "G:\Jasmine\Sydney\lib\site-packages\django\core\urlresolvers.py",
line 3
29, in app_dict
self._populate()
File "G:\Jasmine\Sydney\lib\site-packages\django\core\urlresolvers.py",
line 2
69, in _populate
for pattern in reversed(self.url_patterns):
File "G:\Jasmine\Sydney\lib\site-packages\django\core\urlresolvers.py",
line 3
67, in url_patterns
patterns = getattr(self.urlconf_module, "urlpatterns",
self.urlconf_module)
File "G:\Jasmine\Sydney\lib\site-packages\django\core\urlresolvers.py",
line 3
61, in urlconf_module
self._urlconf_module = import_module(self.urlconf_name)
File "C:\Python27\Lib\importlib\__init__.py", line 37, in import_module
__import__(name)
File "G:\Jasmine\Baillee\Baillee\urls.py", line 25, in <module>
url(r'^usconst/', include('Baillee.apps.usconst.urls')),
File "G:\Jasmine\Sydney\lib\site-packages\django\conf\urls\__init__.py",
line
28, in include
urlconf_module = import_module(urlconf_module)
File "C:\Python27\Lib\importlib\__init__.py", line 37, in import_module
__import__(name)
File "G:\Jasmine\Baillee\Baillee\apps\usconst\urls.py", line 6, in
<module>
url(r'^usconst/$',
Baillee.apps.usconst.views.catland(template_name='statute
.html')),
NameError: name 'Baillee' is not defined
<>
This is with 'Baillee.apps.usconst.views' commented out of the import line
in urls.py -
(Sydney) G:\Jasmine\Baillee>python manage.py shell
Traceback (most recent call last):
File "manage.py", line 10, in <module>
execute_from_command_line(sys.argv)
File "G:\Jasmine\Sydney\lib\site-
packages\django\core\management\__init__.py",
line 385, in execute_from_command_line
utility.execute()
File "G:\Jasmine\Sydney\lib\site-
packages\django\core\management\__init__.py",
line 354, in execute
django.setup()
File "G:\Jasmine\Sydney\lib\site-packages\django\__init__.py", line 21,
in set
up
apps.populate(settings.INSTALLED_APPS)
File "G:\Jasmine\Sydney\lib\site-packages\django\apps\registry.py", line
112,
in populate
app_config.ready()
File "G:\Jasmine\Sydney\lib\site-packages\debug_toolbar\apps.py", line
15, in
ready
dt_settings.patch_all()
File "G:\Jasmine\Sydney\lib\site-packages\debug_toolbar\settings.py",
line 215
, in patch_all
patch_root_urlconf()
File "G:\Jasmine\Sydney\lib\site-packages\debug_toolbar\settings.py",
line 203
, in patch_root_urlconf
reverse('djdt:render_panel')
File "G:\Jasmine\Sydney\lib\site-packages\django\core\urlresolvers.py",
line 5
13, in reverse
app_list = resolver.app_dict[ns]
File "G:\Jasmine\Sydney\lib\site-packages\django\core\urlresolvers.py",
line 3
29, in app_dict
self._populate()
File "G:\Jasmine\Sydney\lib\site-packages\django\core\urlresolvers.py",
line 2
69, in _populate
for pattern in reversed(self.url_patterns):
File "G:\Jasmine\Sydney\lib\site-packages\django\core\urlresolvers.py",
line 3
67, in url_patterns
patterns = getattr(self.urlconf_module, "urlpatterns",
self.urlconf_module)
File "G:\Jasmine\Sydney\lib\site-packages\django\core\urlresolvers.py",
line 3
61, in urlconf_module
self._urlconf_module = import_module(self.urlconf_name)
File "C:\Python27\Lib\importlib\__init__.py", line 37, in import_module
__import__(name)
File "G:\Jasmine\Baillee\Baillee\urls.py", line 25, in <module>
url(r'^usconst/', include('Baillee.apps.usconst.urls')),
File "G:\Jasmine\Sydney\lib\site-packages\django\conf\urls\__init__.py",
line
28, in include
urlconf_module = import_module(urlconf_module)
File "C:\Python27\Lib\importlib\__init__.py", line 37, in import_module
__import__(name)
File "G:\Jasmine\Baillee\Baillee\apps\usconst\urls.py", line 6, in
<module>
url(r'^usconst/$',
Baillee.apps.usconst.views.catland(template_name='statute
.html')),
NameError: name 'Baillee' is not defined
(Sydney) G:\Jasmine\Baillee>
}}}
urls.py -
{{{
from django.conf.urls import patterns, include, url
from jinja2 import Template
from django.views.generic import TemplateView
#from Baillee.apps.usconst.views import *
#why don't i need to import re here?
# Uncomment the next two lines to enable the admin:
from django.contrib import admin
admin.autodiscover()
urlpatterns = patterns('',
url(r'^$', TemplateView.as_view(template_name='home.html')),
# Examples:
url(r'^$', TemplateView.as_view(template_name='home.html')),
url(r'^404', TemplateView.as_view(template_name='404.html')),
url(r'^500', TemplateView.as_view(template_name='500.html')),
url(r'^about', TemplateView.as_view(template_name='about.html')),
url(r'^contact', TemplateView.as_view(template_name='contact.html')),
url(r'^survey', TemplateView.as_view(template_name='survey.html')),
url(r'^join', TemplateView.as_view(template_name='join.html')),
url(r'^pre-sale', TemplateView.as_view(template_name='pre-
sale.html')),
url(r'^library', TemplateView.as_view(template_name='library.html')),
url(r'^testnumbers',
TemplateView.as_view(template_name='testnumbers.html')),
url(r'^usconst/', include('Baillee.apps.usconst.urls')),
#url(r'^ussct/', include('ussct.urls')),
# url(r'^Baillee/', include('Baillee.foo.urls')),
# Uncomment the admin/doc line below to enable admin documentation:
url(r'^admin/doc/', include('django.contrib.admindocs.urls')),
# Uncomment the next line to enable the admin:
url(r'^admin/', include(admin.site.urls)),
)
}}}
usconst/urls.py -
{{{
from django.conf.urls import patterns, include, url
from Baillee.apps.usconst.views import catland, TOC, sectionView
#do i still need these imports if they are in project urls?
urlpatterns = patterns('Baillee.apps.usconst.views',
url(r'^usconst/$',
Baillee.apps.usconst.views.catland(template_name='statute.html')),
url(r'^usconst/Article\s\d[1-5]|[I-V]',
Baillee.apps.usconst.views.TOC(template_name='statute.html')),
url(r'^usconst/Article\s\d[1-5]\s\Section\d[1-5]',
Baillee.apps.usconst.views.sectionView(template_name='statute.html')),
url(r'^usconst/(?P<slug>)',
Baillee.apps.usconst.views.sectionView(template_name='statute.html')),
)
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/22280#comment:27>
Django
different paths
-----------------------------------+------------------------------------
Reporter: blueyed | Owner: nobody
Type: Bug | Status: new
Component: Testing framework | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-----------------------------------+------------------------------------
Comment (by collinanderson):
You have a few different options. I'd recommend this for
`Baillee/apps/usconst/urls.py` :
{{{
from django.conf.urls import patterns, include, url
from Baillee.apps.usconst import views
urlpatterns = patterns('',
url(r'^usconst/$', views.catland(template_name='statute.html')),
url(r'^usconst/Article\s\d[1-5]|[I-V]',
views.TOC(template_name='statute.html')),
url(r'^usconst/Article\s\d[1-5]\s\Section\d[1-5]',
views.sectionView(template_name='statute.html')),
url(r'^usconst/(?P<slug>)',
views.sectionView(template_name='statute.html')),
)
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/22280#comment:28>
Django
different paths
-----------------------------------+------------------------------------
Reporter: blueyed | Owner: nobody
Type: Bug | Status: new
Component: Testing framework | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-----------------------------------+------------------------------------
Comment (by MalikRumi):
YES!!!
I had one more error, but I knew how to fix that, and I am in the shell!
Huzzah! Thank you VERY much!
--
Ticket URL: <https://code.djangoproject.com/ticket/22280#comment:29>
Django
different paths
Reporter: blueyed | Owner: nobody
Type: Bug | Status: closed
Component: Testing framework | Version: master
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by collinanderson):
* status: new => closed
* resolution: => worksforme
Comment:
You're welcome. Way to go! I'll close this ticket.
If you or anyone else runs into this issue, and are still stuck after
reading through the suggestions above, feel free to post the issue on the
django-users group, or IRC.
If anyone can think of way to improve the documentation or error message
feel free to re-open.
--
Ticket URL: <https://code.djangoproject.com/ticket/22280#comment:30>
Django
different paths
-----------------------------------+------------------------------------
Type: Bug | Status: new
Component: Testing framework | Version: master
Severity: Normal | Resolution:
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-----------------------------------+------------------------------------
* status: closed => new
* resolution: worksforme =>
Comment:
This bug breaks IPython autoreloading feature. Modules can not be updated
with this error:
{{{
[autoreload of db.models failed: Traceback (most recent call last):
File "/pyenvs/p3/lib/python3.4/site-
packages/IPython/extensions/autoreload.py", line 247, in check
superreload(m, reload, self.old_objects)
RuntimeError: Conflicting 'language' models in application 'db': <class
'db.models.Language'> and <class 'db.models.Language'>.
}}}
Used "./manage.py shell" which drops me into IPython.
When imported paths are different - this bug can be fixed.
But here we have reloading of absolutely the same file (and path)
Can this error be hidden (at least while settings.DEBUG==True)? Any way to
throw it out?
It just breaks things.
--
Ticket URL: <https://code.djangoproject.com/ticket/22280#comment:31>
Django
different paths
-----------------------------------+------------------------------------
Reporter: blueyed | Owner: nobody
Type: Bug | Status: new
Component: Testing framework | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-----------------------------------+------------------------------------
Comment (by pashinin):
Found a commit:
https://github.com/django/django/commit/aff57793b46e108c6e48d5ce3b889bf90b513df9
#diff-e0a696d19bf764562a439d3080a30fda
--
Ticket URL: <https://code.djangoproject.com/ticket/22280#comment:32>
Django
different paths
-----------------------------------+------------------------------------
Reporter: blueyed | Owner: nobody
Type: Bug | Status: new
Component: Testing framework | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-----------------------------------+------------------------------------
Comment (by collinanderson):
Interesting. Actually, that's a slightly different issue, because those
have the _same_ path. Could you open a new ticket for that? and re-close
this one?
--
Ticket URL: <https://code.djangoproject.com/ticket/22280#comment:33>
Django
different paths
Reporter: blueyed | Owner: nobody
Type: Bug | Status: closed
Component: Testing framework | Version: master
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by carljm):
* status: new => closed
* resolution: => worksforme
Comment:
Re-closing as the issue raised by @pashinin (supporting module reloading)
is really a different issue (despite causing the same error message).
Please file a new ticket for that and we can discuss it there.
--
Ticket URL: <https://code.djangoproject.com/ticket/22280#comment:34>
Django
different paths
-----------------------------------+--------------------------------------
Reporter: blueyed | Owner: nobody
Type: Bug | Status: closed
Component: Testing framework | Version: master
Severity: Normal | Resolution: worksforme
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-----------------------------------+--------------------------------------
Comment (by timgraham):
The new ticket for the above issue is #23621.
--
Ticket URL: <https://code.djangoproject.com/ticket/22280#comment:35>