The attached patch seems to fix this, my colleague ran the 2.x test suite against it and everything passes. I try to run it against trunk (1.3.0 pre-beta) however I think there is something wrong with my setup as I get 13 failures (with or without the patch) In either case We don't think it breaks anything however there is a change this is not tested extensibly.

Why is all of this relevant? The django-hudson extension looks into sys.modules in order to generate the coverage report. Which means that in hudson UI you get some ugly paths like venv/src/your_app/../your_app/path/to/your/code

I don't think it's the same bug. Please note my problem is not limited to runserver. I used that as an example. The actual command we run is django manage.py hudson from the django-hudson app.

As you point out it's the same cause. IMO this bug is the main bug and #15064 is a consequence of this.

You said the patch needs improvement but do not point to how. I don't know this code much but removing the sys.path modifications probably means a mayor rewrite of the way django imports apps. And this code (according to SVN history) hasn't been touch significantly in over two years.

2) This problem has two causes: one is sys.path mangling done by Django; second is a poor report generator in ​coverage.py (this is the module that actually creates the Cobertura report - not django-hudson). First is being tracked by #15064, second is out of scope for Django.

Just making the notification work, as he was the one that assigned the status.

2) This problem has two causes: one is sys.path mangling done by Django; second is a poor report generator in ​coverage.py (this is the module that actually creates the Cobertura report - not django-hudson). First is being tracked by #15064, second is out of scope for Django.

Again I believe #15064 is a subset of this, as this ticket explains the problem better. As for coverage, I don't agree, it's ok that coverage.py generates full path reports based on the module. But as you said that's out of scope.

Reopening - this was closed as duplicate of #15064, but the fix for #15064 didn't actually deal with the core problem, the sys.path mangling done by setup_environ. This ticket is the clearest explanation of that problem that I can find, and thus should remain open.

To be clear, this ticket will be fixed when Django is no longer mucking with sys.path, not just if the mucking is done with an absolute path; thus the attached patch is not adequate.

Marking "needs tests" tentatively - all current tests pass, and the code changes here are almost entirely to the project template, which is currently untested and would need quite a bit of new test harness work to make testable. But I may look into what tests could reasonably be added there.