Hi. This is not a rant, not a vendetta against snap authors, nor a post to say that snaps can’t be used - because I’m sure there are use cases for particular snaps, especially those that are updated and well-maintained.
It’s just that in my experience so far, for certain snaps that I have tried, it has really been a somewhat discouraging experience, and I’m curious about the general opinion about this in the community.
I’ve tried 3 different snaps, mainly for my server/CLI applications:
Tmux
Nano
Htop
Now this is my experience so far with each:
Tmux: Kind-of updated, but throws apparmor errors in the log, and the release channels had a major malfunction some time ago, so it downgraded to a 2,5 year old version (appears it is a known issue, that requires building the snap locally)
Nano: Not updated, latest edge version throws error when trying to run it (known issue), and cannot read /etc/nanorc (minor annoyance, reported)
Htop: Updated, and working after redoing connections etc.
For each of these apps, I’ve found that a much easier and faster way to get the latest version is to download the latest .deb package from pkgs.org and install it with apt. I test on a VM first, but so far there have been no problems at all, and it’s working much better than trying to get the snaps to work.
I didn’t think this would be the case, but maybe we’re still at a place where snaps are just not mainstream enough to replace apt/deb versions of basic programs, even when newer packages can easily be installed with no problems.
At least, so far I’m not convinced to try snaps for packages that are not officially maintained as snap only. The above experience is just way too shaky for me.
Thanks, and have a nice weekend.
EDIT: Htop is working as expected with proper connections and path to manpages. Thanks maxiberta.
Maxiberta, issue has been filed - thanks.
I also commented on the other issues with manpages, since I don’t entirely agree with you on that. If you would include the manpages inside the snap at least (/snap/htop/current/share/man) a workaround can be used, but you didn’t.
Here is tmux. Has a 2.3 version (2017) but the latest is 3.2. Uses the classic confinement. Was created by a Canonical employee but not updated since then.
What should happen, is to have the tmux snap package moved to snapcrafters.
$ snap info tmux
name: tmux
summary: tmux
publisher: Shawn Wang (shawn111)
store-url: https://snapcraft.io/tmux
contact: <reducted>@canonical.com
license: Proprietary
description: |
What is a terminal multiplexer?
It lets you switch easily between several programs in one terminal,
detach them (they keep running in the background) and reattach them to a
different terminal.
And do a lot more.
snap-id: ivk4SNTWlCHYxwOioLptUqikcWDelOeL
channels:
latest/stable: 2.3 2017-05-17 (11) 995kB classic
latest/candidate: ↑
latest/beta: ↑
latest/edge: 2.3 2018-02-22 (74) 1MB classic
$
Run the same command for nano and you get the URL to report issues.
Third-party repos and publication systems do generally have this problem - if the publisher loses interest, the content goes stale.
In general, I think our best strategy here is to avoid content being created for short term purposes. These examples probably stem from me asking people to make snaps to test and experience the tooling first hand. While that accomplished the goal, giving the snapcraft and store teams valuable feedback, it also raised the risk of common things which were outdated in deb repos being snapped and then left behind to go stale.
As a more general principle, perhaps we should have an active monitoring system for places where you have a popular piece of content available as both snap and deb, so that there is a dashboard to highlight issues like this.
Launchpad reminds me of expiring memberships once a year …
Perhaps we could do something similar for snaps that have not been touched by their maintainer for a given amount of time … send a few reminders that you can respond to with a “Yes I still care !” button in the store (or programmatically via snapcraft) … and if there is no reaction within a certain time frame, unlist the snap.
We have a tool that can do this already, in a developer-friendly way. Marketo. It could potentially be fed store data (like last-upload) and gently nudge developers to maybe look at publishing an update. This presumes they read their email of course, and our mail doesn’t look terribad. Personally I really like getting the “Your Month in Snaps”. The web/design/store/marketing team did a good job of getting those looking pretty and being actually useful mails. Perhaps they could do similar for a “nudgenudge your snap is old and crusty” type mail, in a pretty, friendly way.
That’s great, but however nice we craft the mail, without a mechanism to unlist the snaps when there is not any reaction of the packager they will stay and keep rotting in the store …
I think that’s step 2 of N, or a parallel step 1. Having a bot send an email to snaps@canonical.com about outdated snaps is, I suspect, not going to work. It’s my belief (and I have done a lightning talk about this a couple of times at internal events) that snaps shouldn’t collectively be under one email address/account like that. There should be a publicly maintained list of which individual or team owns a snap (which should match what the store page and snap info shows) so anyone can be empowered to reach out and either offer help/pull requests or nudge.
Further, I believe the store should “bury” (down-rank in search results) snaps which haven’t been updated for $TIME. In addition the store pages (and snap info output) could highlight outdated snaps with a simple banner. The goal isn’t to shame the developer (although a bit of that might occur), but empower users to make choices based on up to date information. If they can see “This snap hasn’t been updated since 2016/06/20” perhaps they might choose not to install it, just like a snap with poor ratings / reviews, or one with no metadata.
I think one issue that makes this issue worse is the naming policy is inconsistent throughout the documentation.
The web docs encourage you to avoid taking names such as $PROJECT-$USER, because users of one package cannot be transferred to another package automatically.
Meanwhile, snapcraft register itself encourages you to take $PROJECT-$USER, and claims that users prefer being clearly distinguished if it’s an unofficial package. (And problematically, the snap-store GUI doesn’t even show this at all, which means that the entire point falls flat in the face of one of the biggest methods of actually installing snaps).
And IMO, the result is that someone will make $PROJECT-$USER, maintain it for some time, and eventually stop. The package will end up in documentation around the internet and persist in the store search, any new packages will struggle to compete and differentiate against the older snap, and long story short becomes there’s a lot of different snaps of Minecraft, and none of them are official, nor will they ever become official, because that involves making yet another snap and not replacing the old ones.
I wouldn’t want to give permission to someone to take over a package with my literal name attached to it if it’s not me actually pushing it, and so IMO along with the sentiments above about prioritising newer snaps, the name registration process really needs clarifying so that the web documentation and the snapcraft tool itself don’t compete against each other, and the dispute process should be made clearer for people so that people could at least attempt to recover unmaintained snaps. (Informally I think this already happens every now and then, but I can’t find any official process for it).
I think you all have some good points regarding monitoring content.
And I actually think that the current lack of monitoring is my biggest gripe, since it leads to store content becoming “degraded” to some degree, which again leads to the user becoming disappointed with the quality of the snap packages in question.
This is in sharp contrast to the normal packages which are always kept up-to-date.
So many thanks for the feedback so far to everyone!
A classic snap that was not updated since 2017 should never be in a curated, central store. This leaves users worse off compared to ppa’s that at least get disabled on release upgrades.
I think one of the big issues is allowing anybody to brings snaps to the store for applications they did not write nor own. You could forbid this. Or you could label (and by default only show) snaps that see regular updates.
New or updated snaps should also be noticed on the snapcraft page. I’ve opened a ticket for the snapcraft page more than 6 months ago.
There are apps that I didn’t even know exist as snap because when the developer creates it or updates, it doesn’t show on the main page.
If you would include the manpages inside the snap at least (/snap/htop/current/share/man) a workaround can be used, but you didn’t.