Look at os.environ before early_config

[blueyed]

This breaks a lot of internal tests, which could be adjusted.

I think it makes more sense to prefer the current environment before the
config from (e.g.) setup.cfg.

[pelme]

Yes, it makes sense to change this order and I think it's fine.

I have a slight concern about backward incompatibility, this change might break things for someone, but I think that it is worth merging this.

[pelme]

@blueyed This broke my own test suite when running soon-to-be-2.9.0-release against my own tests. I've added a note in the changelog in 726a63f.

I still think this is a good change, but it was difficult to track down at first when a bunch of unrelated tests random tests just failed in strange ways. Please have a look at the changelog and let me know/feel free to make other changes if you figure out a way to make this more visible/obvious. :)

[blueyed]

it was difficult to track down

We should have information about it with --verbose then probably?

[pelme]

A message that prints which Django settings is used? Something like

=================== test session starts ========================
platform darwin -- Python 2.7.10 -- py-1.4.30 -- pytest-2.7.2 -- /Users/andreas/.virtualenvs/pytest-django/bin/python
cachedir: /Users/andreas/code/pytest-django/.cache
rootdir: /Users/andreas/code/pytest-django, inifile: setup.cfg
plugins: django, cache, xdist, xdist, xdist
django settings module: foo.bar.settings_abc

??

[blueyed]

Yes, and also the origin of it (e.g. option, environment or config).

[pelme]

Yes, that makes sense.

[pelme]

I'll fix it now!

[pelme]

Fixed in 4b0526e :)

[blueyed]

Thanks!

[blopker]

This broke our build.

We use the environment for running the app then use the ini file to override the environment. This way we can run py.test in any folder to run a subset of tests. Now we have to figure out another way to do this.

I guess I don't understand why the change was made. It seems like Django itself always uses the env as a last option.

[pelme]

The reasoning for this change is that typically the .ini file goes into the repository and sets a default settings module. The env var can be overridden (or set to a default in the local environment). Finally the --ds option can be used to override both ini and settings. Django does something similar: it uses the env var but it can be overridden by specifying --settings.

Would putting

addopts = --ds=yourtestsettings

in your ini file solve your problem? That would set the Django settings from the ini-file, but then you cannot override with --ds manually.

[blopker]

Thank you for the workaround, I'll try it out.

All I know is I have a case where having the env last works really well. The addopts key feels like a hack to me. I'd like to see an actual app where letting the env override the ini is desirable.

I have a feeling this is going to bite a lot of people.

Anyway, this has shipped already so I guess I'll just find a way around it.

[pelme]

I think the --ds/env/ini-way is useful in libs where you don't typically define DJANGO_SETTINGS_MODULE in your local environment but expect the ini file to provide it. Then it becomes easy for a single contributor to run tests with a specific test setting most of the time, but then just override it with --ds.

For projects where you use the DJANGO_SETTINGS_MODULE env var in your local environment to run django-admin runserver and other stuff, having the ini-file override the env var makes more sense. You typically have a settings module for development and one for running tests, not multiple settings modules for tests.

I am split by this - this is more convenient for libs (like pytest-django itself) but not for my "real" project. :)

I am thinking about having another ini-style config that you could specify the order yourself (something like django_settings_module_source = option,ini,env) - but that seems kind of overkill too.

I agree that addopts = --ds=foo is a bit of a hack, but so is addopts itself but yet it is practically very useful. :)

@blopker Please let us know if addopts makes it work for you, if not
@blueyed Do you have any thoughts on this?

(If anyone else is reading this and got bitten by this, please drop a line here and let us know!)

[blopker]

I can confirm addopts works! I still think it's not an ideal solution, but it's workable.

Aside from changing it back, I'd suggest adding addopts to the docs.

Cheers!

[blueyed]

JFI: my use case was to easily use different settings from the environment, while there might be a default configured in the config file.

@blopker

We use the environment for running the app then use the ini file to override the environment. This way we can run py.test in any folder to run a subset of tests.

I can see this use case, and could imagine to use --ds myself for different environments.

I also cannot remember if the PR came from working on a project or when working on pytest-django itself.

I think a option like django_settings_module_source would be able to solve this for everybody, especially given that pytest-django tells you where settings are coming from now.

A workaround for @blopker's use case would also be to run py.test as env -u DJANGO_SETTINGS_MODULE py.test.

And after all I'd be OK with changing the default again, of course.

[coveralls]

Changes Unknown when pulling 976bb56 on prefer-django-settings-from-env into * on master*.