-
Notifications
You must be signed in to change notification settings - Fork 5
Developers
This is the place where you will find more instructions for developers. Note that you might also be interested in the Users instructions, especially the embeded scheme, if you have a pure Python application.
The latest version of this plugin can be downloaded from the links above or from the release area. Select the AppImage corresponding to your architecture, e.g. linuxdeploy-plugin-python-x86_64.AppImage.
The executable can be run in standalone mode by specifying a --appdir=AppDir
or as a plugin for linuxdeploy. In the later case it is
activated as:
linuxdeploy [some options...] --plugin python [more options...]
Note that the plugin must be located on the search path of linuxdeploy, E.g. in the same directory.
In order that linuxdeploy properly locates all dependencies, it is recommended to run it two times. A first time with the python plugin, for bundling Python into the AppDir, and a second time without, for installing dependencies.
The behaviour of the plugin can be steered through specific environment variables. For example:
PYTHON_SOURCE="MyPythonSource" \
PYTHON_CONFIG="--enable-optimizations" \
PIP_REQUIREMENTS="package1 packag2=1.0.1 package3" \
[extra varibales for linuxdeploy...] \
linuxdeploy [some options...] --plugin python [more options...]
where MyPythonSource
is a source distribution of Python. Note that
an archive or an url can be provided as well as a local source.
PIP_REQUIREMNENTS
are passed directly to pip
and must conform to its
canonical syntax. For a detailed list of the available configuration variables
run the plugin in standalone (i.e. not through linuxdeploy) with
--help
.
Depending on the source distribution, various Python executables are
built, e.g. python3
, python3.7
, pip3
, etc. You can select one of those as
argument to linuxdeploy --custom-apprun [any python executable...]
or call
them from your own AppRun
entry point.
For best performances, it is recommended to use an explicit AppRun while setting the
--executable
argument of linux deploy to.pythonX.Y
, whereX.Y
refers to your python version, E.g.3.7
. This will help linuxdeploy optimising your image. Note the dot prefix in front of the PythonX.Y binary (see [#Integration] for details).
the commands below builds a Python3.7 AppImage from the online source distribution:
export PYTHON_SOURCE=https://www.python.org/ftp/python/3.7.3/Python-3.7.3.tgz
linuxdeploy-x86_64.AppImage --appdir AppDir \
--plugin python
linuxdeploy-x86_64.AppImage --appdir AppDir \
-i python.png \
-d python.desktop \
-e AppDir/usr/bin/.python3.7 \
--custom-apprun AppDir/usr/bin/python3 \
--output appimage
Below are extra technical details, E.g. in case one wants to build a more complex application based on this plugin. Note that if your application is a pure Python one, it might be more relevant to follow the embeded scheme rather than building a dedicated AppImage with your extra packages.
-
The Python installation is done to a fixed prefix:
${APPDIR}/usr
, inside the AppDir. -
The Python binaries located in
${APPDIR}/usr/bin
are substitued by wrappers. Those allow to forward the source executable ($ARGV0
) to Python and to ensure that the system install, inside the image, is properly found. Yet, you want to use the native binaries you must prefix their name with a dot, E.g..python3.7
, or substitute them back.Note that using the native binaries has several shortcomes due to the non relocability of some Python builtin functionalities, as well as to the fact that the install residing in the AppImage has a non static mount point.
-
The Python installed inside the AppImage uses a sitecustomize.py file in order to prune the default install location (
/usr/local
) from the search path. This allows to isolate the Python running in the image from the host system packages.Yet, if you need to keep the host system packages visible you can add their location to
PYTHONPATH
.