pytest --version might better avoid loading config

[yarikoptic]

• [x] Include a detailed description of the bug or suggestion

not sure if easily doable but ideally the --version shouldn't depend on parsing config etc, and just spit out a version of pytest since it might be the one to decide either config needs to be patched etc. ATM for me that fails:

(git)hopa:~exppsy/pandas[debian]git
$> pytest --version              
usage: pytest [options] [file_or_dir] [file_or_dir] [...]
pytest: error: unrecognized arguments: --strict-data-files
  inifile: /home/yoh/deb/gits/pkg-exppsy/pandas/setup.cfg
  rootdir: /home/yoh/deb/gits/pkg-exppsy/pandas

• [x] pytest and operating system versions

$> apt-cache policy python-pytest
python-pytest:
  Installed: 3.6.2-2
  Candidate: 3.6.2-2
  Version table:
 *** 3.6.2-2 600
        600 http://http.debian.net/debian sid/main amd64 Packages
        600 http://http.debian.net/debian sid/main i386 Packages
        100 /var/lib/dpkg/status

[pytestbot]

GitMate.io thinks possibly related issues are https://github.com/pytest-dev/pytest/issues/3050 (deprecate pytest.config), https://github.com/pytest-dev/pytest/issues/98 (Config._checkversion checks installed pytest version), https://github.com/pytest-dev/pytest/issues/1831 (support for [tool:pytest] given/other config files), https://github.com/pytest-dev/pytest/issues/3106 (Exit code 1 when pytest crashes on loading plugin), and https://github.com/pytest-dev/pytest/issues/1411 (Pytest stops).

[asottile]

pytest --version does more than just produce the pytest version, it also produces versions for plugins:

$ pytest --version -c /dev/null
This is pytest version 3.6.3, imported from /private/tmp/t/venv/lib/python3.7/site-packages/pytest.py
setuptools registered plugins:
  pytest-cov-2.5.1 at /private/tmp/t/venv/lib/python3.7/site-packages/pytest_cov/plugin.py

Which, you can also disable with the configuration:

[pytest]
addopts = -p no:cov

And that suppresses those plugins:

$ pytest --version
This is pytest version 3.6.3, imported from /private/tmp/t/venv/lib/python3.7/site-packages/pytest.py

Not saying it _shouldn't_ act as you're describing, but I suspect there's current information that is produced in the --version output that wouldn't be possible _without_ parsing the configuration.

[joooeey]

Why was this closed? The issue is still present in pytest 5.4.1.

[asottile]

pytest _needs_ to parse the configuration in order to derive some information that may (or may not) be displayed in --version

[joooeey]

I see. How do I fix or work around the error the OP described: pytest: error: unrecognized arguments: --strict-data-files?

[asottile]

I suspect you're missing a plugin which implements that argument -- or you can remove the configuration, or you can ignore the configuration with something like pytest -c /dev/null --version or cd / && pytest --version

[joooeey]

Thanks! I solved the specific pandas error given in the OP by navigating to the inifile given in the error message and removing the line that contains --strict-data-files. Hopefully that doesn't break anything.

[nicoddemus]

Hmmm that got me an idea... perhaps we should have this instead:

$ pytest --version
5.4.2

And:

$ pytest --version -v
This is pytest version 5.4.2, imported from d:\projects\pytest\src\pytest\__init__.py
setuptools registered plugins:
  hypothesis-4.36.0 at d:\projects\pytest\.env36\lib\site-packages\hypothesis\extra\pytestplugin.py
  pytest-forked-1.1.1 at d:\projects\pytest\.env36\lib\site-packages\pytest_forked\__init__.py
  pytest-xdist-1.31.0 at d:\projects\pytest\.env36\lib\site-packages\xdist\plugin.py
  pytest-xdist-1.31.0 at d:\projects\pytest\.env36\lib\site-packages\xdist\looponfail.py

This seems more in line with how other tools implement --version.

[asottile]

or we could do like cpython:

$ python3 --version
Python 3.6.9
$ python3 --version --version
Python 3.6.9 (default, Nov  7 2019, 10:44:02) 
[GCC 8.3.0]

[nicoddemus]

Ahh right, good idea. 👍

But do we want:

$ pytest --version
5.4.2

Or:

$ pytest --version
pytest 5.4.2

?

I slight prefer the former, if it doesn't make much difference.

(the --version --version output is the same)

[asottile]

either seems fine to me, I have no preference between the two alternatives

[hugovk]

I think it's a good idea to include the tool name, python, pre-commit and black do this.

Could be useful in case you've aliased it.

[nicoddemus]

Oh if more tools include the name, I agree we should go with the flow.

I will open an issue.

[nicoddemus]

https://github.com/pytest-dev/pytest/issues/7128 👍