KEkeymone·Nov 16, 2021
In Python: Please stop screwing over Linux distrosspotify
dh-virtualenv
Python2014–2021
spotify / dh-virtualenv
dh-virtualenv
Python virtualenvs in Debian packages
8Distinct people
9Mentions
0Explicit recommenders
1.6KGitHub stars
What to know before exploring
What it is
Python virtualenvs in Debian packages
GitHub
Where it is used
No documented product use has been verified yet.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year9 dated mentions
Observed mentions: 2014-11-14 19:24:21 UTC to 2021-11-16 11:15:20 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 2 | 0 | 2 |
What Hacker News says
9 sourcesI'm in a devops role where we actually reroll the Tensorflow whl in-house (to get a few tweaks like specific AVX flags turned on), but because the rest of our deployment is apt/debs, we then turn around and wrap that whl in a deb using Spotify's excellent dh-virtualenv:
https://github.com/spotify/dh-virtualenv
There's no expertise for Bazel in-house; when we run the build, it seems to fail all its cache hits and then spend 12-13h in total compiling, much of which appears to be recompiling a specific version of LLVM.
Every dependency is either vendored or pinned, including some critical things that have no ABI guarantees like Eigen, which is literally pinned to some random commit, so that causes chaos when other binaries try to link up with the underlying Tensorflow shared objects:
https://github.com/tensorflow/tensorflow/blob/master/third
Read the rest
_p...
And when you go down a layer into CUDA, there are even more support matrices listing exact known sets of versions of things that work together:
https://docs.nvidia.com/deeplearning/tensorrt/support-matrix...
Anyway, I'm mostly just venting here. But the whole thing is an absurd nightmare. I have no idea how a normal distro would even begin to approach the task of unvendoring this stuff and shipping a set of reasonable packages for it all.
The Tensorflow maintainers themselves even kind of admit the futility of it all when they propose that the easiest thing to do is just install your app on top of their pre-cooked Tensorflow GPU docker container:
https://www.tensorflow.org/install
I recently came across this: https://github.com/spotify/dh-virtualenv
For a system utility, you can still use virtualenvs. The launcher script just needs to use a shebang like:
#!/usr/share/spiffyapp/venv/bin/python
In Remacs – A community-driven port of Emacs to RustPerhaps this is useful for you? https://github.com/spotify/dh-virtualenv
In Show HN: Virtualenv-mv – Move (rename) Python virtualenvsWe usually stick to the official Debian python-* packages (if they exist upstream). When they don't we use python-virtualenv[1][2] to pull specific versions and dependencies from pip into a virtual env.
Now when we build our Debian package (debian/rules):
override_dh_virtualenv:
dh_virtualenv -p myproj --use-system-packages
[1] https://github.com/spotify/dh-virtualenv
[2] https://packages.debian.org/jessie/python/python-virtualenv
In Python Patterns (2013)Note that the base path /usr/share/python (that dh-virtualenv ships with) is a bad choice; see https://github.com/spotify/dh-virtualenv/issues/82 for a discussion.
You can set a different base path in debian/rules with export DH_VIRTUALENV_INSTALL_ROOT=/your/path/here
In How We Deploy Python CodeYou can build debian packages that way; dh-virtualenv (https://github.com/spotify/dh-virtualenv) makes it quite easy to pack a full virtualenv into a .deb.
In Pip -t: A simple and transparent alternative to virtualenv in PythonI tried a few things myself, like fpm[1], rpmvenv[2] and lately pex[3] - but so far, I haven't found something, that I would call solid and simple. We have constrained deployment environments that do not allow most of the tools, that would ease the process on a development machine. Basically, I need a deb or rpm.
I have some hopes to wrap a pex into deb/rpm, but I would not call this approach simple.
That's unfortunate since Python is a wonderful language for many data-sciency tasks - Python makes things possible and pleasant, that would be a pain in other languages.
* [1] https://github.com/jordansissel/fpm
* [2] https://github.com/kevinconway/rpmvenv
* [3] https://pex.readthedocs.org/en/latest/
* Another tool: https://github.com/spotify/dh-virtualenv
In Pip -t: A simple and transparent alternative to virtualenv in PythonYou could also try virtualenvs inside Debian packages:
https://github.com/spotify/dh-virtualenv
One reason to keep virtualenvs is that the system Python (VM or container) includes extra Python packages that your app may or may not need. If you use a virtualenv, you exclude these system-installed packages and guarantee a clean starting point.
In After Docker: Unikernels and Immutable Infrastructure