Learning Python as a Sysadmin

As the title suggests, I originally learnt Python in 2005/2006 as a sysadmin language, to replace the aging Perl as a systems management scripting language. The "Batteries-included", rich standard library were appealing, and the "explicit is better than implicit" mantra promised an easier time for new joiners and better comprehension later than Perl's short symbol vars ($| = 1 anyone?). Since I was managing systems that were based on a Linux distro and had a package manager, when I needed database drivers or a server framework, I was just installing the packaged python modules using apt or yum.

This did mean that I pretty much never interacted with the ecosystem - and up to the time that I applied for a full-stack developer role in 2016, I'd never used pip or virtualenv. That was a shock.

Python package-management's detractors are fully vocal elsewhere, but I am still wondering why virtualenv has as many moving parts as it does. Virtualenvs seem to be a bit brittle too - after moving my home directory to a new machine with an updated Python, the stub python executable inside a virtualenv issues an opaque complaint before exiting, signalling that the virtualenv needs to be rebuilt, again.

For contrast, PHP just used an include_path configuration directive to locate libraries/modules. Include_path could be specified in a global php.ini, or a project-specific one, and seemed to work OK. The nearest analogue for Python would seem to be the PYTHONPATH environment variable, and that seems to work too. pip even seems to work quite well with this, using the -t parameter to install the requested modules to a target directory instead of ~/.local or the system/virtualenv site-packages.

Protecting the distro-managed Python from conflicts arising from random Python modules installed with pip is still well-worth doing. Anyone who's managed to break yum by installing modules to site-packages with pip will relate.

For my own stuff, I'm tending to use pip -t to install modules to a lib/ directory adjacent to the project directory, and setting PYTHONPATH in the systemd unit that runs the service. Works well enough for me. Virtualenv as a development tool is still fine, but I'm still left with the feeling that using virtualenv in production deployments has an anti-pattern feel to it.