Working with Python¶
No pip¶
Do not install a global system-wide version of pip at all.
There is almost never a good reason to install global system-wide packages via pip to begin with. Especially on Linux where the default version of Python is part of the system and used by the system. So mixing this with Python projects that the user install install themselves via pip is very likely to cause conflicts sooner rather than later.
Use isolation¶
If Python tools are needed to be always available from the command line, then isolate them with zapp, shiv, or pex.
Those are all zipapp single-file Python executables.
shiv and pex applications are self extractable. zapp does not need to be extracted. The code is executed directly from within the zip-compressed archive.
pex applications are executed from their own virtual environment. zapp applications are not executed in a virtual environment. Not sure about shiv.
shiv applications show up somehow in the current environment. Whereas zapp applications do not, so they are perfect for tools such as deptree, and pipdeptree.
Use toolmaker¶
To automate the creation of single file Python applications with zapp, shiv, or pex, one can use toolmaker.
Use venv¶
Python 3 has the module venv in its standard library since version 3.3.
So the need for the third party library virtualenv is much less pressing.
$ python3 -m venv .venv
$ . .venv/bin/activate
Do not activate virtual environments¶
The scripts that are installed in a virtual environment (with setuptools at least) get a shebang with the full path to the Python interpeter from the virtual environment. So there is no need to activate the virtual environment to call such scripts.
$ .venv/bin/myscript
$ .venv/bin/python3 -m mymodule
Interactive debug¶
breakpoint()
python -i main.py
python -i -m something
import pdb; pdb.set_trace()
Then:
(Pdb) interact
*interactive*
>>>
Or:
import code; code.interact(local=locals())