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

Consider creating Snap package #47

Open
Jackenmen opened this issue Jul 7, 2022 · 9 comments
Open

Consider creating Snap package #47

Jackenmen opened this issue Jul 7, 2022 · 9 comments

Comments

@Jackenmen
Copy link
Contributor

The probably most popular distros - Debian 11+/Ubuntu 18.10+ and Fedora 30+ - do not have the autotrash package in their repositories anymore. Arch and openSUSE Tumbleweed seem to be the only two mainstream distros that do have an up-to-date package.

Would you consider creating a Snap package for this project if someone (maybe me 🙂) contributed it along with the CI setup? Currently the only way to install autotrash on one of the aforementioned distros seems to be installing autotrash with pip in ~/.local/bin but considering that this project can auto-delete all trash directories, not just the one in one's home directory it is not ideal to have a non-global binary for it. An added bonus would be auto-setup of a systemd service which can also be done by snap.

@MithicSpirit
Copy link
Contributor

Might also be worth considering a flatpak instead of or in addition to a snap since most distributions (other than Ubuntu) seem to either prefer flatpak or be indifferent between the two.

@Jackenmen
Copy link
Contributor Author

I don't think flatpak works that well for terminal apps sadly. Support for shipping system services seems to be even worse. Snap (sometimes rightfully) gets a lot of hate but it does offer a better experience in some regards, both for packagers and end-users.

It certainly doesn't help that Canonical forces people to use snap for things where they're not ready and the experience is subpar rather than push it for things where it actually provides a better experience :P

@bneijt
Copy link
Owner

bneijt commented Jul 9, 2022

I do not have the snap toolchain setup currently, but willing to give it a try. Feel free to open a PR if you want, all help is appreciated. It might take some time for me to review because it's going to be my first snap.

@bneijt
Copy link
Owner

bneijt commented Jul 9, 2022

Immediately ran into a wall, I'm using Archlinux so I'm not sure atm whether I can develop and support snaps: https://bugs.launchpad.net/snapcraft/+bug/1981130

@midnight-wonderer
Copy link

midnight-wonderer commented Jul 14, 2022

ping: @QkiZMR
want to assist on this? (probably with CI, GitHub Actions, maybe)

@QkiZMR
Copy link

QkiZMR commented Jul 15, 2022

Hi, I created snap for autotrash but it was an old version
https://github.com/QkiZMR/Snaps/blob/master/autotrash/snap/snapcraft.yaml
Somebody created an issue in my repo to update autotrash QkiZMR/Snaps#1. I will update it, I will do it next week.

@Jackenmen
Copy link
Contributor Author

Hi, I just want to say that I (author of the issue) personally am no longer interested in this feature request. Snapcraft's policy makes it unlikely that such a package would be accepted for classic confinement and without it, autotrash's usefulness is (IMO, at least) very limited.

Personally, I decided to instead set up pipx on my system in such a way that it can install packages globally and I'm using autotrash like that. I think that my time is better spent on looking into whether pipx can be further improved to work better for global package installs (pypa/pipx#754) rather than using my energy to try getting classic confinement for a package.

I have not had much luck with getting classic confinement for a different package which was similar in scope so I had to adjust my expectations :)
https://forum.snapcraft.io/t/classic-confinement-for-jack1142-trash/30806/5

The idea behind my request was to improve the packaging situation for autotrash in a system-agnostic way, not really using snap specifically so I want to share one alternative solution for this problem (aside from global pipx).
While looking into other system-agnostic package managers, I've found out that Nix package manager is actually not only available on NixOS and can be installed on any Linux system using systemd so if someone is interested in making a system-agnostic package (other than the already recommended one on Python's PyPI) then their effort might be better spent there.

I leave the decision on what to do about this feature request up to @bneijt as it seems there are others that might still be interested in it.

@midnight-wonderer
Copy link

Wow!! That's news to me.
I thought anyone could distribute a classic snap package.
And the fact that Snap store is close-sourced; if I don't have prior knowledge about Snap, I thought we were dealing with Apple.

What options do we have now? AppImage?

@Jackenmen
Copy link
Contributor Author

Wow!! That's news to me.
I thought anyone could distribute a classic snap package.

Nope, this was always the case.

And the fact that Snap store is close-sourced; if I don't have prior knowledge about Snap, I thought we were dealing with Apple.

Yeah, snap isn't perfect from the open-sourceness standpoint. Centralization in itself is fine (language package managers such as pip are a prime example of it) but the lack of a way to set a custom index to install from like you can do with language package managers is incredibly bad. Nonetheless, from the project maintainer's standpoint and user's standpoint snap is incredibly convenient.

What options do we have now? AppImage?

Nix :) Or in the case of this project, also pipx since it's a Python package.

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

No branches or pull requests

5 participants