Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Packaging #2

Open
patri9ck opened this issue Nov 18, 2021 · 13 comments
Open

Packaging #2

patri9ck opened this issue Nov 18, 2021 · 13 comments
Labels
enhancement New feature or request

Comments

@patri9ck
Copy link
Owner

patri9ck commented Nov 18, 2021

Distribution Packaged Maintainer
PyPi Yes patri9ck
AUR Yes patri9ck
Debian No
NixOS No
Ubuntu No
Fedora No
Void Linux No
@patri9ck patri9ck added the enhancement New feature or request label Nov 18, 2021
@beankylla
Copy link

Available to test the fedora package ☺️

@patri9ck
Copy link
Owner Author

Unfortunately, there is none as far as I know

@Jan9103
Copy link
Contributor

Jan9103 commented Dec 26, 2022

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-dev
  • pip3 install PyGObject pycairo
  • PKG_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.


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.

@patri9ck
Copy link
Owner Author

Thanks for the effort! That would be great!

@patri9ck patri9ck changed the title Package to more distributions Packaging Jan 20, 2023
@Jan9103
Copy link
Contributor

Jan9103 commented Jan 28, 2023

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.

@luqmanishere
Copy link

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.

@beankylla
Copy link

i'm reading about all this packaging and wondering if flatpak is not an easier way to get this done?

@Jan9103
Copy link
Contributor

Jan9103 commented Mar 18, 2023

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)
  • there is a distro independent method: pip
  • i have no experience with packaging for flatpak and assume its not easier than app-image

@patri9ck
Copy link
Owner Author

patri9ck commented Mar 23, 2023

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.

@yozachar
Copy link

yozachar commented Jul 4, 2023

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?

@patri9ck
Copy link
Owner Author

patri9ck commented Jul 12, 2023

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!

@Alter-RK
Copy link

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!

@octvs
Copy link

octvs commented Mar 25, 2024

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 supported

Previously 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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

7 participants