I&#x27;ve been thinking a bit about python and packaging, and I think there are few reasons to wrap the bootstrap process of packages like this in a shell script. As python is already a hard dependency, it should be somewhat easier to write a cross-platform bootstrap in python, than in posix shell (hello, windows?). It <i>is</i> a little unfortunate that expressing &quot;needs python, headers and a c compiler&quot; is as hard as it is. But if dependencies are beyond the (reasonable) reach of pip&#x2F;setuptools, it seems it might make sense to simply defer to some other package that already deals with this stuff, such as ansible.<p>Nothing against automating systems with shell (or Makefiles) -- but it seems to result in much duplication of effort (eg: duplicating stuff from the &quot;os&quot; package in python&#x27;s std lib) -- with an added burden when trying to support a variety of Linux and * bsd distros.<p>Writing a posix shell installer that works &quot;idiomatically&quot; on Debian is easy. Writing one that works across old-stable, stable and testing is a little more complex. Adding support for Ubuntu LTS along with the slew of Ubuntu-releases newer than previous LTS, can already get messy. Add inn SuSe, RedHat, Arch, Slackware and GNU Guix... and that&#x27;s not even thinking of Open Solaris or the * BSDs.<p>It&#x27;s not that it can&#x27;t be done, but I think the only sane choice is to get upstream to do the hard work (eg: port&#x2F;package python w&#x2F;&quot;os&quot;, port&#x2F;package ansible -- or use something else, like package-config or ... autotools...).<p>I think the best way is probably to distribute a <i>python</i> script that sets up a virtualenv, and runs pip from within that to pull down&#x2F;set up a package. I&#x27;m not yet quite sure if this is viable for python2x though... bringing venv into the std-lib is one great (and I think often overlooked) feature of python3.