Packaging
patri9ck opened this issue · 12 comments
| Distribution | Packaged | Maintainer |
|---|---|---|
| PyPi | Yes | patri9ck |
| AUR | Yes | patri9ck |
| Debian | No | |
| NixOS | No | |
| Ubuntu | No | |
| Fedora | No | |
| Void Linux | No |
Available to test the fedora package
Unfortunately, there is none as far as I know
Hi,
i started to try and package it for debian wanted to share a few notes in hope of them being useful.
Note: i'm not too experienced with it and might have misunderstood / forgotten / … something
Debian packages
Debian python packages are usually a bit special since debian offers its own set of python dependencies in their repositories (usually called python3-NAME), which are commonly outdated (and inconsistent between versions, distros, etc) and for example pyzmq doesn't seem to be packaged at all.
It is possible to just add python3-pip as a dependency and run a postinstall script (which isn't a best practice).
If we ship pip it makes sense to just install ALL dependencies via pip to avoid duplicate sub-dependency installation, wrong versions, etc.
But if we just install pip anyway i don't really see a reason to package it as a debian package instead of just shipping it via pip. Pip also has the upside of being OS independent, which lets us avoid having to package it for each distro separately.
i haven't looked at it to much, but maybe pacstall (aur for debian) would be a idea (a package script for a git python project).
Pip / Pypi packages
Note: my debian installs commonly have issues no one else seems to be able to reproduce, therefore the following might be specific to my computer (but according to some google searches it seems as if others have similar issues)
While trying to package it for pip i also ran into a issue: during the installation of a built package it fails with No package 'py3cairo' found ……… ERROR: Could not build wheels for pygobject, which is required to install pyproject.toml-based projects.
This issue seems to already be somewhat well known, but at least on my system none of the fixes and workarounds worked:
apt install libgirepository1.0-dev python3-gi python3-gi-cairo gir1.2-gtk-3.0 python3-cairo libcairo2-devpip3 install PyGObject pycairoPKG_CONFIG_PATH=/usr/lib/python3/dist-packages pip3 install …
the issue might be due to the debian package being named python3-cairo, the required package being named py3cairo and the pip package beeing called pycairo.
The error also appears when doing pip3 install -r requirements.txt, but i was able to install it in the past by just using pip3 install Pillow pygobject pyzmq setproctitle qrcode (which is supposed to do the exact same i think), but that's not an option if we package it for pypi since we have to use the pyproject.toml as far as i am aware.
Also: packaging it probably requires some restructuring (official packaging tutorial)
Other packaging options
With pip issues with dependency-version clashes aren't uncommon in my experience. It is possible for the end user to use venvs, but try to explain that to a average user.
I wouldn't be surprised if fedora, void, etc will have similar issues to debian and pip.
Therefore it might make sense to package it as flatpak or appimage (and maybe add a .deb wrapper around the app-image to ease installation). AppImages are larger in size since dependencies are included, but this project is pretty small and size is not as important as it used to be.
- a probably simple method to package it as app-image is python-appimage
i might take a look at nix, appimages or pacstall later, but don't expect any results.
if i or we get something to work i might be up for maintaining a package.
Thanks for the effort! That would be great!
in case someone wants to help with packaging it for nixos (NUR for now): i have a half-working package: it starts, but for some reason the pairing times out without any error: https://github.com/Jan9103/nur-packages/blob/a2ln/pkgs/a2ln/default.nix.
in case someone wants to help with packaging it for nixos (NUR for now): i have a half-working package: it starts, but for some reason the pairing times out without any error: https://github.com/Jan9103/nur-packages/blob/a2ln/pkgs/a2ln/default.nix.
The derivation you made works with v1.1.10, just make sure the firewall allows the pairing ports or is off alltogether. NixOS defaults to having the firewall on.
i'm reading about all this packaging and wondering if flatpak is not an easier way to get this done?
i think flatpak is a great package-manager, and im all for more install actively maintained install methods,
but i wont maintain a flatpak version due to a few reasons:
- i dont use flatpak myself (currently i only use nix (and steam) as my package manager):
- i use a window manager and therefore the start command via flatpak would be:
flatpak run com.github.patri9ck.a2ln-server - flatpak requires another update command, etc and just adds unnecessary complexity for me
- flatpak programs take up more resources (not much, but its easy to avoid)
- i use a window manager and therefore the start command via flatpak would be:
- there is a distro independent method: pip
- i have no experience with packaging for flatpak and assume its not easier than app-image
Flatpak would probably be a good addition. Unfortunately, I don't have time to implement it by myself at the moment - at least it does not have a big priority for me with there being other installation methods like pip as mentioned before. It would be great if someone else maintained it or at least created a PR adding all the necessary meta files and a functioning build - then I could also maintain it considering future updates.
Hi @patri9ck, I can help containerizing the server. Which will run on all platforms with podman or docker or something similar. It also can be started on boot. With your permission, may I start working on it, in my spare time?
Hey @joe733, sorry for the recent inactivity. Containerizing the server would be great to provide another installation option for users. Feel free to work on it!
We really hope for the flatpak version or the app-image. It's a bit difficult to put the server on the same debian 13. Thank you for your work!
The derivation you made works with v1.1.10, just make sure the firewall allows the pairing ports or is off alltogether. NixOS defaults to having the firewall on.
Is this still the case @luqmanishere? I have tried the derivation from your nix config with fw disabled to no avail:
Traceback (most recent call last):
File "/nix/store/hir20ya35p2a3z0n5nglv06dyjawk280-a2ln-1.1.10/bin/..a2ln-wrapped-wrapped", line 9, in <module>
sys.exit(main())
^^^^^^
File "/nix/store/hir20ya35p2a3z0n5nglv06dyjawk280-a2ln-1.1.10/lib/python3.11/site-packages/a2ln/a2ln.py", line 67, in main
zmq.auth.create_certificates(own_keys_directory, "server")
File "/nix/store/vpgqa91mq2y6vb9ylchzcfmlpwgz2c0i-python3.11-pyzmq-25.1.2/lib/python3.11/site-packages/zmq/auth/certs.py", line 71, in create_certificates
public_key, secret_key = zmq.curve_keypair()
^^^^^^^^^^^^^^^^^^^
File "zmq/backend/cython/utils.pyx", line 60, in zmq.backend.cython.utils.curve_keypair
File "/nix/store/vpgqa91mq2y6vb9ylchzcfmlpwgz2c0i-python3.11-pyzmq-25.1.2/lib/python3.11/site-packages/zmq/error.py", line 149, in _check_rc
raise ZMQError(errno)
zmq.error.ZMQError: Operation not supportedPreviously I attributed the error to pyzmq, thus waited NixOS/nixpkgs#294305 to land, bumping its version 25.1.2, at the end it did not resolve the issue.
Cheers