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 .jar file.

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 CLASSPATH.

In Python:

  • A .py (or .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, it merges with other directories of the same name elsewhere on sys.path into a single package).
  • A .zip archive 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.

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.

However, .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.

Easy Install from setup_tools defines the .egg format for deploying Python libraries or applications. While similar to JAR, it is nowhere spread as universally as JARs in Java world. Many people just deploy the .py files.

A newer format, intended to supersede eggs, is wheel.

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”:

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 containing:

print "Hello world from Python"

Zip up the Python files (in this case just this one file) into by typing:

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
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:

python app

Or you can run it directly from the command line: