Each Answer to this Q is separated by one/two green lines.
Java has the concept of packaging all of the code into a file called a Jar file. Does Python have an equivalent idea? If so, what is it? How do I package the files?
Python doesn’t have any exact equivalent to a
There are many differences, and without knowing exactly what you want to do, it’s hard to explain how to do it. But the Python Packaging User Guide does a pretty good job of explaining just about everything relevant.
Here are some of the major differences.
A .jar file is a compiled collection of classes that can be dropped into your application, or installed anywhere on your
.pyc) module can be dropped into your application, or installed anywhere on your
sys.path, and it can be imported and used.
- A directory full of modules can be treated the same way; it becomes a package (or, if it doesn’t contain an
__init__.py, it merges with other directories of the same name elsewhere on
sys.pathinto a single package).
.ziparchive containing any number of modules and packages can be stored anywhere, and its path added to your
sys.path(e.g., at runtime or via
PYTHONPATH) and all of its contents become importable.
Most commonly, you want things to be installed into a system, user, or virtualenv
site-packages directory. The recommended way to do that is to create a
pip-compatible package distribution; people then install it (and possibly automatically download it from PyPI or a private repo) via
pip does a lot more than that, however. It also allows you to manage dependencies between packages. So ideally, instead of listing a bunch of prereqs that someone has to go download and install manually, you just make them dependencies, and someone just has to
pip install your-library. And it keeps track of the state of your site-packages, so you can uninstall or upgrade a package without having to track down the specific files.
Meanwhile, in Java, most
.jar files are cross-platform; build once, run anywhere. A few packages have JNI native code and can’t be used this way, but it’s not the norm.
In Python, many packages have C extensions that have to be compiled for each platform, and even pure-Python packages often need to do some install-time configuration. And meanwhile, “compiling” pure Python doesn’t do anything that can’t be done just as well at runtime. So in Python, you generally distribute source packages, not compiled packages.
.wheel is a binary package format. You can
pip wheel to build binary packages for different targets from the source package; then, if someone tries to
pip install your package, if there’s a wheel for his system, that will be downloaded and installed.
Though it’s not a perfect susbstitute of jar due to portability issues, I would add the “auto-extracting” archive way.
One possibility is “makeself”: https://makeself.io/
But if you don’t need to package external files, and if you like KISS approach, the following is a nice and clean alternative:
The following is taken from Asim Jalis’s website.
How to deploy a Python application as a zip file
Create a file
print "Hello world from Python"
Zip up the Python files (in this case just this one file) into
app.zip by typing:
zip app.zip *
The next step adds a shebang to the zip file and saves it as
app—at this point the file
app is a zip file containing all your Python sources.
echo '#!/usr/bin/env python' | cat - app.zip > app chmod 755 app
That’s it. The file
app is now have a zipped Python application that is ready to deploy as a single file.
You can run
app either using a Python interpreter as:
Or you can run it directly from the command line: