Develop Reference

pytest or py.test, and inconsistent documentation

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?

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.
create virtualenv
run pytest --version (it will complain that pytest has no --version)
pip install pytest
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!

How to make Travis CI to install Python dependencies declared in tests_require?

I have Python package with setup.py. It has regular dependencies declared in install_requires and development dependencies declared in tests_require, e.g. flake8.
I thought pip install -e . or running python setup.py test will also install my development dependencies and they'll be available. However, apparently they're not and I struggle to setup my Travis CI build right.
install:
- "pip install -e ."
script:
- "python setup.py test"
- "flake8"
Build configured as above will fail, because flake8 will not be found as a valid command. I also tried to invoke flake8 from inside of the python setup.py test command (via subprocess), but also without success.
Also I hate the fact that flake8 can't be easily made integral part of the python setup.py test command, but that's another story.

I prefer to keep most of the configuration in tox.ini and rely on it to install and run what is to be run. For testing I use pytest (the solution can be modified to use other testing frameworks easily).
Following files are used:
tox.ini: automates the test
.travis.yml: instructions for Travis
setup.py: installation script to install the package to test
test_requirements.txt: list of requirements for testing
tox.ini
[tox]
envlist = py{26,27,33,34}
[testenv]
commands =
py.test -sv tests []
deps =
-rtest-requirements.txt
.travis.yml
sudo: false
language: python
python:
- 2.6
- 2.7
- 3.3
- 3.4
install:
- pip install tox-travis
script:
- tox
test_requirements.txt
Just ordinary requirements file whith what ever you need in there (e.g. flake8, pytest and other dependencies)
You may see sample at https://github.com/vlcinsky/awslogs/tree/pbr-setup.py
The fact it uses there pbr, coverage and coverall is not relevant to my answer (it works with or without pbr).

The more direct answer is that pip install will not install tests_require, intentionally separating runtime requirements from test requirements. python setup.py test creates a virtualenv-like environment to run the tests in, un-doing this afterwards. flake8 is thus unavailable once it is done.
Flake8 has setuptools integration and also integrates with pytest if you use that. pytest itself also integrates with setuptools.

Installed Nose but cannot use on command line

I installed Nose on a Mac OSX 10.10.5 with Python2.7.9 using easy_install. The installation appeared to be successful:
Collecting nose
Downloading nose-1.3.7-py2-none-any.whl (154kB)
100% |████████████████████████████████| 155kB 2.3MB/s
Installing collected packages: nose
Successfully installed nose-1.3.7
But now, when I try even basic stuff with nosetests on the command line, like nosetests -h or which nosetests I just get:
bash: nosetests: command not found
I have tried uninstalling, reinstalling using pip, tried installing with sudo and then running sudo nostests in the directories with tests scripts as other posts have suggested, but nothing seems to work.
The original purpose for installing was to use nose to run some basic tests with tests scripts I had written for these simple web.py apps. But nothing works, just keep getting the command not found response.
What's strange is that, when I open up the Python interpreter in Terminal, and do something like:
import nose
nose.main()
I get the expected result of:
.
----------------------------------------------------------------------
Ran 1 test in 0.135s
OK
So clearly it's installed....somewhere. Any suggestions for what the hell is going on here?

There are lots of error occurred when using pip install packages on Mac OS. So I recommend you install nose using easy_install.
$ pip uninstall nose
$ sudo easy_install nose
Then you can try nosetests now :)

I had this exact issue on OS X EI Captain with Python 2.7.10.
First I installed nose using pip:
$sudo pip install nose
which failed on the first attempt. Went through on the second attempt. But the nosetests command didn't work.
In order to fix this:
Step 1: Don't uninstall nose if it was installed already using pip as in my case.
Step 2:
$cd /usr/bin
$sudo easy_install nose
Above command finds the nosetests script (which was installed by pip earlier) & sets it under /usr/local/bin
Step 3: Try nosetests
$nosetests
----------------------------------------------------------------------
Ran 0 tests in 0.047s
OK

On UNIX-like systems like OS X, the script should be in /usr/local/bin. Make sure that directory is in the PATH environment variable in the shell that you use.
If not, you can also locate it using find, e.g:
find / -type f -name 'nosetests*' -perm +111 -print -quit
This means; search for a file whose name starts with nosetests, which has execute permissions set. Print the path name and stop.

I found that going to
Library/usr/bin
and running
sudo easy_install nose
it seems that sometimes it doesn't automatically install nose (and therefore nosetests functionality). Do the above lines, and you should be a-ok.
I wish i had a better explanation for why this happened, but i'm still pretty new, myself.

I had to use
Nosetest
or
python3 -m "nose"
Apparently this is the way Nosetest should be used in Python3. See also
How to make nosetests use python3

First, can you run 'python' from the command line? nosetests should be in that same directory:
rich bin $ which python
/home/rich/anaconda/bin/python
rich bin $ which nosetests
/home/rich/anaconda/bin/nosetests
It should also be in the downloaded nose package:
rich bin $ find /home/rich/anaconda -name nosetests
/home/rich/anaconda/pkgs/nose-1.3.3-py27_0/bin/nosetests
/home/rich/anaconda/pkgs/nose-1.3.7-py27_0/bin/nosetests
/home/rich/anaconda/bin/nosetests

From what I understand, everyone is moving to pytest - an actively-maintained testing framework.
It's not a solution to this problem, but it's likely the most-appropriate choice if you are still using nose.

I try to reinstall the pip, it doesn't work but lastly, when i use sudo ...it works
pip3 uninstall nose
sudo pip3 install nose
and
which nosetests
/usr/local/bin/nosetests

This can also happen if you were running nose within a virtual environment, and that virtual environment has been deactivated. If this is the case, reactivate with source bin/activate.

pylint doesn't point to virtualenv python

I am pretty new to python and currenty I am trying to use pylint for checking code quality. I am getting a problem. My pylint doesn't point to virtualenv python interpreter. Here is the output that I get when I run pylint --version
$ pylint --version
pylint 0.21.1,
astng 0.20.1, common 0.50.3
Python 2.6.6 (r266:84292, Jul 10 2013, 22:48:45)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-3)]
In virtualenv I have python 2.7 installed. Will appretiate you help if someone can point me to how to solve that.

A cheap trick is to run (the global) pylint using the virtualenv python. You can do this using python $(which pylint) instead of just pylint. On zsh, you can also do python =pylint.

I am fairly sure that you need to install pylint under your virtual environment and then run that instance of it.
Update - Make life easier:
I would suggest that anybody working a lot in virtual environments create a batch file, (in a known location or on the path), or bash script with something like the following called something like getlint.bat:
pip install pylint
Invoking this after activating the virtual environment will install pylint into that virtual environment. If you are likely to be offline or have a poor internet connection you can, once when you have a good internet connection, (possibly once for each of python 2 & 3):
mkdir C:\Some\Directory\You\Will\Leave\Alone
pip download --dest=C:\Some\Directory\You\Will\Leave\Alone pylint
Which will download pylint and its dependencies to C:\Some\Directory\You\Will\Leave\Alone and you can modify getlint.bat to read:
pip install pylint --find-links=C:\Some\Directory\You\Will\Leave\Alone
It will then use the pre-downloaded versions.

Noufal Ibrahim's answer works if you execute pylint manually.
If you execute pylint from you editor/IDE, you need to configure the plugin correctly.
vim/syntastic
atom/linter-pylint
...
It can get tricky. This may be considered a bug of each IDE/plugin, but that's how it is.
Modifying /usr/bin/pylint to write #!/usr/bin/env python as suggested in another answer fixes this for every use of pylint (manual use, or any editor integration).
However, at least in Debian, using #!/usr/bin/python is a design choice, not a bug. See here for the rationale.
To avoid modifying that system file, one can create a copy of /usr/bin/pylint in /usr/local/bin:
cp /usr/bin/pylint /usr/local/bin/pylint
vi usr/local/bin/pylint # Edit the file to use /usr/bin/env python
This won't be broken by a pylint update, but still infringes Debian's "strongly preferred choice".
This method requires root privileges. An unprivileged user may create an alias
alias pylint='/usr/bin/env python $(which pylint)'.
I always develop in virtualenv and I setup a postmkvirtualenv hook to install pylint and flake8 automatically when creating a virtualenv, so I don't use the versions ditributed by debian anymore.

I ran into this problem, too. My solution was simply to edit the pylint program's shebang, like so... (your path to pylint may be different than mine, though)
$ sudo vim /usr/bin/pylint
Replacing:
#!/usr/bin/python
With:
#!/usr/bin/env python

The issue has been solved on chat (link in comments).
The problem lied in using sudo yum install pylint, because it installed pylint in the global env. The solution was to use the following command:
pip install -i http://f.pypi.python.org/simple pylint
Note the -i usage as the regular index seemed to be broken for the asker.

I know it's been a while since this question was answered, but I just thought I should leave this post here in case someone else runs into the same problem.
If for some reason you need to keep pylint in the global space instead of your virtual environment, you can use the recommendation in here: PyLint + VirtualEnv.
It basically says to configure your pylint using the init-hook and encoding version of a Python program that will use the global pylint and load the rest of the environment.

You can get there by calling the target python interpreter:
./env/bin/python -m pylint ...
# or in an already active env
python -m pylint ...

When you're using Pipenv / virtualenv, install pylint inside the virtualenv:
pipenv install --dev pylint
or, if you don't use Pipenv, install it with pip after you activated your virtualenv:
# activate virtualenv, e.g. `. env/bin/activate`
pip install pylint

I'm using the Syntastic + Pylint combination, and since I have many different virtualenvs that I can work on at any given time, I've created a wrapper over the virtualenv command that, among some other things, installs pylint after all the requirements.
That way, whenever I activate a virtualenv, I'll get its own pylint version.
Hope this helps, and thanks for the tip on deleting the global one from #briford-wylie

Ran into the same problem just today. Continuing on ThorSummoner's answer, when using Pylint with pylint-django inside of a virtual environment such as Pipenv, make sure to call pylint using the target python interpreter (python -m pylint)
A good approach, which will work locally and on your CI as well is to write-down the lint command in the script section of your Pipfile:
[scripts]
lint = "python -m pylint [--options] all-my-modules-names..."
Then calling pylint is as easy as :
pipenv run lint

Testing a python script in a specific version

I currently have Python 2.6.2 installed on my mac. I am writing a script which MUST run on Python 2.5.2. So I want to write a python script, and test is specifically against 2.5.2 and NOT 2.6.2.
I was looking at virtualenv, but it doesn't seem to solve my problem. I ran python virtualenv.py TEST which made a TEST dir, but it had python 2.6 in it. Is there a way to make virtualenv use a different version of python than what's installed default on my machine? Is another way to use the #! as the first line of the python script? How would I do that?

Check out tox; it's designed to do exactly this.
Here is an example of using tox to run a hello_world.py script against multiple Python versions:
Install tox
pip install tox
Create a tox.ini configuration file
[tox]
envlist = py39, p310, p311
[testenv]
commands = python hello_world.py
The envlist option specifies the Python versions to test against
The commands option specifies the command to run in each environment
Run tox
tox
This will create separate environments for Python 3.9, 3.10, and 3.11 and run the hello_world.py script in each environment.

You can setup a sandboxed environment with different python versions using virtualenv. As Kable has done, install the 2.5. version you want to test against. Then create your virtual environment:
virtualenv --p=python2.5 myapp
To get a clean environment you may use the --no-site-packages switch with the command above. Quite handy when trying to simulate a new, fresh setup. Now activate your virtualenv:
source myapp/bin/activate
If you check the python version you should now get version 2.5.x:
python -V
Now you can install modules as you like into your virtual environment in the usual fashion:
easy_install ...
pip ...
To exit your virtual environment:
deactivate
Hope this may be of help.

You could just install a Python 2.5.2.
I have 3 different versions Python installed on my Lucid and they use different links under /bin/ so it's easy to call the specific version
python -> python3 ->python3.1
python2 -> python2.7
python2.5

try #!/path/to/your/python/version
But make sure you execute the script from the terminal, and make it executable before hand: chmod 755 myscript.py

Using 'virtualenv' you can have different isolated Python environments on a single machine. Also you can switch any-time between the different python interpreter versions.
What is virtualenv?
A Virtual Environment is an isolated working copy of Python which allows you to work on a specific project without worry of affecting other projects. It enables multiple side-by-side installations of Python, one for each project. It doesn’t actually install separate copies of Python, but it does provide a clever way to keep different project environments isolated.
How to install?
pip install virtualenv
To create virtual environment for python 2.7 :
root:~# which python2.7
/usr/bin/python2.7
root:~# which python3.4
/usr/local/bin/python3.4
You can also use a Python interpreter of your choice:
root:~# virtualenv -p /usr/bin/python2.7 Vpy27
Running virtualenv with interpreter /usr/bin/python2.7
New python executable in /root/Vpy27/bin/python2.7
Also creating executable in /root/Vpy27/bin/python
Installing setuptools, pip, wheel...done.
To begin using the virtual environment, it needs to be activated:
root:~# source Vpy27/bin/activate
The name of the current virtual environment will now appear on the left of the prompt:
(Vpy27) root:~# python -V
Python 2.7.3
Install packages as usual, for example:
(Vpy27) root:~# pip install junos-eznc >> All pip installs done here, will be available only in this environment.
If you are done working in the virtual environment for the moment, you can deactivate it:
(Vpy27) root:~# deactivate
To create virtual environment for python 3.4:
root:~# which python3.4
/usr/local/bin/python3.4
root:~# virtualenv -p /usr/local/bin/python3.4 Vpy34
root:~# source Vpy34/bin/activate
(Vpy34) root:~# python -V
Python 3.4.4
There is also a way to create virtual environment with already available site-packages.