PyTest and Best Practices - package and test vs dev

in «tip» by Michael Beard
Tags: , , , , , , ,

Best Practices and Hints on What to Do

There are lots on interesting tips and tricks, apparently, that you should be doing, if you're going to do things right! I've never packaged a Python module, so this is fascinating to me.

Here are the links I found:

As user obestwalter states in the first link:

As a general recommendation: Always run tests against your installed package. If your package is not installable yet: make it installable. When you develop, install your package with pip install --editable <path/to/package>. When you need to release it somewhere: test the package with tox.

I am speaking from a place of major pain in the past, when I was not doing these things myself and when packaging was in a much worse state than it is today. That all went away now and is replaced by major packaging pains 😀

But joking aside: in most cases it is really much easier to create a simple setup.py to make your project installable and run tests against that, than going through all this hackery to make it work without.

Another user, agrees with obestwalter but has a good reason (with examples) of why you might want to do a hack to temporarily circumvent this (not recommended, but sometimes, you gotta do what you gotta do). I thought it was insightful.

@obestwalter has the correct solution. However, if you need something temporary while you are developing a package, you can simple add the following file to your tests directory, and then pytest will run it before the tests (so no changes are needed per-file when you make a final package, you just delete this one file):

conftest.py

python import os import sys sys.path.insert(0, os.path.abspath(os.path.join(os.path.dirname(__file__), '..'))) (This is one of the top google results for this error, so adding this even though the issue is closed)

PS: This is a hack, please use the editable install solution unless you have good reason to use this one. And do not forget to remove this before publishing to PyPI.

Here is his reason:

this is just useful if you aren't ready to do an editable install or in special cases; and if so, this is a better solution than one non-editable example shown above because it converts much more easily to the correct solution.

In my case, I'm temporarily testing locally against CERN ROOT, and that has to be done against the system python on a Mac, and ROOT does not support pretty much anything nice in Python like virtual environments very well. This is a good way to temporarily test (once it's in Travis, I can test against system Python there). My packages (from cookiecutter) is already installable from moment 0, I just don't want to mess with my user directory by installing the system python one. So I'm sure there is at least one special case where this is useful. :)

So, looks like I need to read/understand how to package a Python module as well. Always fun!