I don’t see how that’s tedious since a compute does that for me. Although I don’t see any value at wheeling them (and some packages cannot be wheeled); my CI builds a venv and puts it into a container. There’s nothing tedious about it at all. I find the idea of running throwaway environments to generate a big blob of tarball'd python+libs, then copying said tarball to actual containers, a rather retrograde step by comparison with established package/build infrastructure tools.
I have to disagree here: I don’t want build tools of any kind in my final containers therefore I build my artifacts separately no matter what language. Of course you can just build the venv on your build server without wheeling up a temporary container and then package it using Docker or DEB or whatever. You should be separating building and running anyway so Python – as much as I’d like Go-style single binaries too – is in no way special here. The nice thing about temporary containers though is that I can do all of that on my Mac.
It's worth pointing out that if you don't want a Go build toolchain in your container, you have exactly the same problem.
I thought I pointed that out in my very first sentence. :D What I don't quite understand is how people can be in love with Go’s static linking but complaining about Virtualenvs in deployments. Unwieldy as virtualenvs are: *for Python code* they are exactly that: statically linked build artifacts. The principles are very similar, the execution is arguably better for Go.