It's not. some people are solving this problem with https://github.com/conda/conda. There are many ways to use conda for deployment. My preferred approach is the following:
For builds:
- build a conda environment for your project
- export your conda environment using conda list -e, and then take all the conda packages for those and put them into a single tarball
For deployment
- bootstrap a base python environment using miniconda http://conda.pydata.org/miniconda.html
- install that tarball of packages with conda install <mytarball.tar>
It's not as simple as a jar, but it's reasonably close
Sorta. It's not that easy in practice (although not terribly, hard since you can package up your python project with setuptools and then deploy it to an internal (or actual) PyPI followed up by using distribution packages for a wsgi server like gunicorn, mod_wsgi, etc). In reality, you typically care about third-party modules enough and building rpms/debs is typically not fun enough that you just have the normal pip/virtualenv story.
There is a solution from Twitter that my devops team has been flirting with called PEX[1]. It builds all of your dependencies into a zip file similar to a jar and sets it up to work by just putting it on your pythonpath. This would in practice be very similar to an uberjar.
Actually, building rpm/deb is quite easy, setuptools handles bdist_rpm by itself, for bdist_deb there is a plugin. For windows folks, bdist_msi is by default part of setuptools[1]. As a backup plan, you can still build eggs with bdist_egg and let pip handle the package manager duties for you.
The real complexity comes elsewhere - both in java and python world, setting up the java application server or wsgi server for python is more involved than just dropping an app there. And then there comes the debugging the exceptions... there I would pretty much prefer the python world.
Also, be careful with zipping python projects. While .zip is a valid member of pythonpath, packages can have problems with finding their assets (if they have any). For example, you cannot zip django this way.
[1] It even handles setting up vcvars when building native extensions. I was impressed, it was easiest building of windows binaries for free software I've ever seen.
Except that bsdist_rpm only builds the current package. That's not really any different than pip. You'd need to recursively build packages for all of the dependencies and have some magic to autodetect the provides/requires inside your little package ecosystem to be reasonable for any non-trival app to be deployable via rpm. This isn't impossible, but it's a far cry from PEX or uberjar.
For builds: - build a conda environment for your project - export your conda environment using conda list -e, and then take all the conda packages for those and put them into a single tarball
For deployment - bootstrap a base python environment using miniconda http://conda.pydata.org/miniconda.html - install that tarball of packages with conda install <mytarball.tar>
It's not as simple as a jar, but it's reasonably close