Menu
How can I distribute a standalone Python application in Linux?
I think I can take for granted the presence of a recent Python interpreter in any modern distribution. The problem is dealing with those libraries that do not belong to the standard library, i.e. wxPython, scipy, python cryptographic toolkit, reportlab, and so on.
Is there a working Linux counterpart to, say, py2exe (which, by the way, I have never tried)? Is there a free, opensource one?
685
Use PyInstaller, py2exe, Nuitka, or another bundling solution. The most convenient way to deliver a Python application to a user is to provide them with an executable—either a single file or a directory with an easily identified executable somewhere in it.
Yes, it is possible to compile Python scripts into standalone executables. PyInstaller can be used to convert Python programs into stand-alone executables, under Windows, Linux, Mac OS X, FreeBSD, Solaris, and AIX. It is one of the recommended converters. py2exe converts Python scripts into only executable on the Windows platform.
I've created the python-build-standalone project for automating the process of building Python interpreters suitable for use with standalone, distributable Python applications. The project produces (and has available for download) binary artifacts including a pre-compiled Python interpreter and object files used for compiling that interpreter.
I think you can fairly safely take for granted python support on most modern Linux distributions - for the ones without it as long as a sane error message is given, users should probably be able to work how to get it on their own (you can use a simple bash startup script for this): #!/bin/bash if [ -e /usr/bin/python ] then echo "Python found!"
There are a handful of tools like PyInstaller which automate the process of building your Python application (often via standard setup.py mechanisms), assembling all the requisite bits of the Python interpreter, and producing an artifact that can be distributed to end users.
Create a deb (for everything Debian-derived) and an rpm (for Fedora/SuSE). Add the right dependencies to the packaging and you can be reasonably sure that it will work.
135
You can use cx_Freeze to do this. It's just like py2exe (bundles together the interpreter and and startup script and all required libraries and modules), but works on both Linux and Windows.
It collects the dependencies from the environment in which it is run, which means that they need to be suitable for the destination as well. If you're doing something like building on 32 bit Debian and deploying on another 32 bit Debian, then that's fine. You can handle 32/64 bit differences by building multiple versions in appropriate environments (e.g. 32 bit and 64 bit chroots) and distributing the appropriate one. If you're wanting something more generic (e.g. build on Debian, deploy on any distribution), then this gets a bit murky, depending on exactly what your dependencies are.
If you're doing a fairly straightforward distribution (i.e. you know that your build environment and deploy environments are similar), then this avoids the rather complex rpm/deb/egg/etc step (using cx_Freeze is very easy, especially if you're familiar with py2exe). If not, then anything from rolling your own dependancy installer to deb/rpm/egg/etc building will work, depending on how much work you want to do, how much flexibility with required versions you want to offer, and what the dependencies are.
42
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
