Python sucks

!> [!WARNING]

This is an unfinished draft.

Python packaging sucks

Trust me, it's what 10/10 experts say. Anylinux-AppImages/HALL-OF-FAME

Yes, python is omnipresent, but your system python is not the latest and greatest. So to be specific, the packaging of python applications and its dependencies sucks. And you must have realized my dependency heavy approach for python. I will include a dependency if it would save me from writing a single line of code for a given task. Well, not to be hyperbolic here, but the idea is that, for modern electrical engineering workflows, if you are a non-programmer, you will have easier time using key third party packages/libraries to have a maintainable and readable codebase.

uv tried to make it better with a significant effort (in my opinion) put into python-build-standalone, but its support for airgapped setups and truly relocatable virtual environments and zippable python with dependencies leaves much to be desired. See uv research for more details.

Currently, a python appimage is the best working solution I have found.

The code for this can be found in misc repository/python_appimage

Almost everything is documented within

• justfile
• builder_script
• pyproject.toml

TODO: Figure out a way to get zola ssg to pull remote code during build time. (Either as a shortcode or as a code block.)

Hacks with AppImage

Always use extracted AppImage. function appimage_extract is an example on how to do it.

After that, you can try running the following command to see if it points to the correct python binary. It will give you the absolute path of python binary (that is referenced by AppRun).

python -c "import sys; print(sys._base_executable); print(sys.prefix)"

Virtual environment using uv

I wish there was a way to not use .venv here, but I haven't found it yet. Here you need to enter the absolute path to the python binary that you obtained from the previous command.

Python AppDirs follow the Manylinux installation scheme. Executable scripts are installed under the AppDir/opt/pythonX.Y/bin directory, where X and Y represent the major and minor version numbers, respectively. Site packages are located under AppDir/opt/pythonX.Y/lib/pythonX.Y/site-packages. For convenience, applications installed using pip are also mirrored under AppDir/usr/bin using symbolic links. Docs

uv venv --relocatable --python /home/<user_name>/.local/bin/.python-appdir/opt/python3.14/bin/python3.14 --system-site-packages

Sadly, we are back to the olden days (pre uv days) where you have to activate the virtual environment manually using source .venv/activate.fish.

You can verify the contents of .venv/pyenv.cfg.

home = /home/<username>/.local/bin/.python-appdir/opt/python3.14/bin
implementation = CPython
uv = 0.11.0
version_info = 3.14.0
include-system-site-packages = true
prompt = python

Making ty and ruff work with venv

To make tools that rely on discovery using .venv and the stuff it provides we have added the absolute path to the python binary and also made sure that the system site packages are discovered. That should be enough. Another way that seems to work for now is adding extra-path in [tool.ty.environment] in pyproject.toml.

Research

UV offline, relocatable setup references

This is where I keep my research on current progress of uv's capabilities for offline, relocatable setups.

Other Attempts

• Zipapps: This might be a blocker for a good amount of dependencies if I understand correctly.
• conda: Conda is meant to exclusively solve the issue of running on older linux, however, having a relocatable virtual environment looked like a hassle with many trip wires last time I checked.

TODO

• Is relocatable needed and/or useful?
• Figure out how to use uv for offline airgapped setup.