2

I decided to give it a go.

Virtualenv is up (python 3.5.2) pip install -U pytest (according to: https://docs.pytest.org/en/latest/getting-started.html).

Next documentation says I should run:

$ pytest --version
This is pytest version 3.x.y, imported from $PYTHON_PREFIX/lib/python3.6/site-packages/pytest.py

But this is actually what I got:

$ pytest --version
Usage: pytest [OPTIONS] [testfile [testpattern]]

examples:

pytest path/to/mytests.py
pytest path/to/mytests.py TheseTests
pytest path/to/mytests.py TheseTests.test_thisone
pytest path/to/mytests.py -m '(not long and database) or regr'

pytest one (will run both test_thisone and test_thatone)
pytest path/to/mytests.py -s not (will skip test_notthisone)


pytest: error: no such option: --version

But if I run:

py.test --version
This is pytest version 3.9.1, imported from ${HOME}/${V_ENV}/lib/python3.5/site-packages/pytest.py

According to that answer:

"py.test" vs "pytest" command

py.test is old (deprecated they say) and pytest is way to go.

I checked both of them:

$ which pytest
$HOME/$V_ENV/bin/pytest

$ which py.test
$HOME/$V_ENV/bin/py.test

Exactly same files.

$HOME is my home, but $V_ENV is where I keep my virutalenvs (I use virtualenvwrapper).

When running tests:

It works:

$ py.test tests/

It does not (exception):

$ pytest tests/

I checked stack trace.

py.test runs using python3 (correct) pytest runs using python2 (incorrect, it's from os)

Anyone knows what is going on?

Also looks like py.test and pytest are exactly the same, so this notion of not using py.test seems a bit obsolete. Am I correct in saying that?

Drachenfels
  • 3,037
  • 2
  • 32
  • 47
  • 3
    `py.test` is the old name where `pytest` was part of a large package named `py` (which is not developed anymore). once they moved to a separate package, they changed the name to `pytest`. The command `py.test` is deprecated and will be eventually removed. I guess your issue results from a bad installation of `pytest`, presumably because you used `--user` when installing in a virtual env. Create a new virtual env and reinstall from scratch: `/path/to/venv/bin/pip install pytest`, does the issue still appear? – hoefling Oct 18 '18 at 16:27
  • It was not --user switch, but your suggestion was on point. I started from scratch and figured out it's working. Next culprit was list of installed libraries, I checked them and I found `py` you mentioned. I checked what installed it as dependency and it was a lib called tox. Library that is suggested to go super well with pytest itself and the internet says go pytest with tox. It will save your time and effort. So now is another exercies, what to do with tox so that it won't install py. :-D Cheers! – Drachenfels Oct 19 '18 at 11:40

1 Answers1

0

As it happens py is installed in system python libraries (as probably yet another dependency of something). There is a consistent way to to reproduce the bug. It involves following steps.

  1. create virtualenv
  2. run pytest --version (it will complain that pytest has no --version)
  3. pip install pytest
  4. run pytest --version (it will complain that pytest has no --version)

And it will stay this way. However if you deactivate and activate env or outright close shell and reopen it, it will fix it.

=== Old Anwer ===

Thanks to @hoefling, he nudged me correct direction!

There is an old library called py that is installed as dependency of tox. It looks like that under certain circumstances related to installation and/or running those two libraries you may end up with corrupted install. Initially I thought it was outright order of installation (install tox first then pytest second) but I was unable to reproduce that. So current working theory is that I run tox first causing it to create invalid virtualenv and then I have installed pytest that got corrupted PYTHONPATH or PATH.

In short. There is a way to corrupt with tox your pytest, if it happens start from scratch people!

Drachenfels
  • 3,037
  • 2
  • 32
  • 47
  • Judging by the repro steps you mentioned, it looks like you have some issues with your setup; a virtualenv shouldn't interfere with the system python. It may vary from a modified `PYTHONPATH` env var somewhere in the `.bashrc`, to modified `virtualenv.py` module. This is the main problem you have to sort out, as errors may happen with other packages as well. – hoefling Oct 20 '18 at 14:36