There's actually a really nifty app, whose name escapes me at the moment, that does this for virtually any linux program (not just python).
It was a wrapper that calls your program, figures out the actual runtime dependencies and essentially creates an image of the all necessary components and bundles it up.
I really wish I could remember its name, but it was designed for science researchers to help them publish reproducible code.
py2pp for the Mac. It appears there is a py2deb and py2rpm for Linux, and I imagine users of Arch, Slack, etc. would be expected to download a .tgz and `setup.py install` it.
Yeah py2deb or py2rpm are great. Now do the same for all your dependencies. And their dependencies. And their dependencies. And their ...
Single artifact does not mean 'your code'. It means 'the whole damn project including all dependencies recursively'.
Think myapp-1.0.war that contains all dependent JAR files. Drop it in a container and it runs. Or your Go compiled tool that is one single static executable that has no reference to external code or libraries. Run it and it works.
I know how I can package my own Python code. I am not too worried about that. I am however really tired of packaging the whole thing every time. And then dealing with stupid things like python packages that need a C compiler to build. Or specific patches to dependent C libraries. Or specific versions of things that some distro might not have. Or dependencies for which I need a newer version than the OS provides. Or .. sigh .. there are so many stupid gotchas that are complete time wasters to deal with.
The main thing you need to understand is that "source code" vs. "single deployable artifact" are impossible to evaluate without considering platform requirements.
Source code is very compatible across many architectures and operating systems but needs compilation, configuration, and dependencies. Binaries are highly compatible with a single platform and work out of the box. However they are not very compatible with any other platform.
The downside is that if you want any feature not provided by the JVM's abstraction layer, at the very least you are in the exact same boat as a python developer.
Ah, of course, you would want to create a slackpkg for Slack, and push to the AUR for Arch. It's still good to offer the .tgz as a baseline for users of systems you might have forgotten or not have time to package for though, (BSD, etc.).
JFTR: the absolutely same is possible in Python.