because (and correct me if I am wrong) Jars (and certainly Wars) contain other bits than the part you wrote.
let's say you are packaging up a java and a python "program". Both print Hello world to the stdout, but use a third party spell checking package. Both the venv and the jar will contain that third party package
All python needs to go from venv to jar is a tarball process.
that is roughly were I see us going anyway - ps anyone with good understanding of jar files please jump in - I would love to map out the python parts against the jar parts (ie pip install is what part of the java setup process?)
Python also understands zip format for modules. So you run
zip -r mymodule.zip mymodule/
and you have the same portability as you have with jar. For bonus points, you can append that zip to a copy of the python executable (either python.exe or whatever binary your OS uses) and it is available as a module for that instance of python. This is one way standalone Python program executables are distributed.
(this was only tangentially related, but I think it's cool. I may also be wrong)
> but use a third party spell checking package. Both the venv and the jar will contain that third party package
Jar files do not support including third party libraries. You simply cannot put a jar in a jar. Eclipse/maven etc can explode the dependancies class files inside of the jar, but people rarely do that for anything other then distributing binaries of client apps (licensing becomes a massive pain btw).
war/ear files on the other hand does support including dependant jar files.
I may have mis-spoke (could not re-read thanks to my antiprocrast) : I am thinking of a package format, probably more similar to .deb than .jar, that will drop the code I have written, plus the third party packages, plus the system level packages, ie all the dependancies that can get compiled)
The idea is to divide the Operating system from the application. There is never a good divide point but at some point we can say the chef/puppet/salt infrastructure will give us the operating system, and the big binary blob (.deb) will give us everything else.
Throw in configuration as a seperate function and I am going to have to lie down in a dark room.
let's say you are packaging up a java and a python "program". Both print Hello world to the stdout, but use a third party spell checking package. Both the venv and the jar will contain that third party package
All python needs to go from venv to jar is a tarball process.
that is roughly were I see us going anyway - ps anyone with good understanding of jar files please jump in - I would love to map out the python parts against the jar parts (ie pip install is what part of the java setup process?)