I end up doing some real crazy stuff:
* build in docker
* using virtualenv /usr/local/mypackage
* then manually copy over the init scripts "cp /usr/local/mypackage/bin/* /usr/local/bin"
* and debianize "/usr/local/mypackage/" and "/usr/local/bin".
Except it doesn't work:
* I need root do create the venv in /usr/local.
* This technique copies garbage like "activate" script to bin.
* virtualenv ships its own python binary. If the python version on host differ, it won't work.
* The workaround is to rewrite the bin scripts.
Total mess. All I need is a deb with some bin scripts, and all dependencies bundled. Is it _that_ hard...
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.
*  https://github.com/jordansissel/fpm
*  https://github.com/kevinconway/rpmvenv
*  https://pex.readthedocs.org/en/latest/
* Another tool: https://github.com/spotify/dh-virtualenv
How about using dh_python? And if you're building in docker anyway, why use virtualenv?
> All I need is a deb with some bin scripts, and all dependencies bundled.
Ah, that would be a problem. Python .debs are supposed to depend on separate python module packages, not bundle everything.
For what you're doing, have you considered turning your entire program into a single executable Python zipfile? See youtube-dl for an example.
virtualenv -p python2.7 env_name
virtualenv --python=/some/path/to/python env_name
You've made the best argument for using pip like this, however. Instead of having to install a virtualenvironment and install dependencies and all of that, you could just ship your program with the pip -t libraries, though you'd have to include the path somehow on the install so python knew where to find those files.
python setup.py --command-packages=stdeb.command bdist_deb
Virtualenv installs some .so files in its thing, so venv directory is tightly coupled with the python binary it runs. Ie: you need to sort it out on the moment you build venv, and shipping venv directory is not correct.
I can't see why that cannot be adapted to .deb packages as well...