Consider removing Snap

[Winterhuman]

Checklist

• [X] I am reporting a documentation issue in this repo, not https://docs.ipfs.io.
• [X] I have searched on the issue tracker for my issue.

Location

https://github.com/ipfs/go-ipfs/blob/master/README.md

Description

Although not extremely numerous, IPFS issues related to Snap appear somewhat consistently with new users, a containerized format does not mesh well with IPFS's capabilities and use-cases, it also doesn't help that the errors produced by Snap installs are very vague which makes troubleshooting difficult. This could be partially solved by recommending snap install --classic ipfs to eliminate some of the issues, however, I propose a more substantial workaround. Removing Snap altogether.

Deb and RPM packages would be a much more useful alternative to Snap in a number of ways, they are more common place than Snap and do not require a secondary package manager to be installed, go-ipfs already provides a tar.xz release (https://github.com/ipfs/ipfs-desktop/issues/691#issuecomment-499302207) so moving to Deb and RPM shouldn't require too much effort (Also see https://github.com/ipfs/go-ipfs/issues/5471).

I'd particularly be interested in hearing from someone in the IPFS team to find out why Snap was chosen originally to give insight into this.

(Sorry in advanced if docs wasn't the right category for this issue, none seemed more appropriate for packaging-related issues)

[bertrandfalguiere]

I'm not from PL, but I think Snap was supported because it is the default package manager on Ubuntu, and it was hard to put in on apt which also installed by default on Ubuntu and more commonly used, IIRC.

[kallisti5]

I had a ton of random issues with the snap package on my wife's ubuntu laptop. Finally gave up and used the binary release which worked fine.

[aschmahmann]

Agreed that there are issues with Snap. We could ask Canonical to get us approved for classic. If there are README updates you'd like to make to add clarity beyond what's there that's fine too but things seem documented already.

None of the package mangers are explicitly supported by go-ipfs and are mostly community maintained. If there's a simple CI action we can use to deploy to a package manager then we do that to make life a little easier. However, whether we automatically publish a Snap or not someone else will and we'll end up with support requests anyway (IIUC the go-ipfs snap was previously community run before we had a CI action).

[lidel]

fwiw i filled request for classic in https://forum.snapcraft.io/t/ipfs-classic-request/28516 when we got :+1: there, I will flip flag in https://github.com/ipfs/go-ipfs/blob/master/snap/snapcraft.yaml#L15 and end this nonsense

[aschmahmann]

Reopening just to track the snap switch to classic mode.

Brief summary:

• Snap confinement makes many CLI tools (from jq to go-ipfs essentially unusable)
• Removing our blessing/CI deployment for Snap does nothing since others in the community will (and previously did) publish Snap which resulted in us getting complaints anyway. All removing the CI integration would do is increase the attack surface on users
• We've asked Snap to let us use classic confinement which will remove much of the nonsense, it still needs to go through their processes

[aronchick]

Confirmed - IPFS_PATH fails to get passed through and the binary fails without explanation.

[aronchick]

BTW, it's perfectly reasonable to use another install method, because IPFS requires so little - crates, debian - even a bash script - is preferrable to me.

[lidel]

I’d like to note that every time Snap discussion surfaces every few weeks, it ends up being a time sink and Snap maintenance creates a disproportionate burden to everyone involved (snap has ~4k users).

ipfs-cluster got granted classic confinement but it still caused maintenance issues when API key expired, and they removed Snap support in 2019: https://github.com/ipfs-cluster/ipfs-cluster/issues/593#issuecomment-436618889

Unless someone familiar with Snap wants to step up and drive this forward, I suggest we limit the time sink caused by Snap, pased on result of this thread:

• if we are granted classic confinement, we update one line in readme and that is all
• if we are not granted classic we should not sink more time in figuring out Snap incantations and fixing it every time it breaks:
  • hand over maintenance to someone from the community
  • update docs and readme's to clearly state Snap is not officially supported and the package is community-maintained

[Winterhuman]

@lidel Any update on getting classic? It seems https://forum.snapcraft.io/t/ipfs-classic-request/28516/9?u=lidel hasn't progressed

[kallisti5]

Snap has been a dumpster fire lately.

Is there even any real demand for Snap packages anymore? Flatpak is in use on most of the distro's i'm aware of. Gnome software manager even dropped support for Snap due to the ongoing issues with it and lack of maintainers.

Pretty much anyone using Ubuntu (and really buying into the ecosystem) is going to grumble about missing snap packages... however the rest of Linux distros moved on from Snap a long time ago.

[Winterhuman]

It's a shame there's no Flatpak, last time it was discussed that I know of was https://github.com/ipfs/ipfs-desktop/issues/686

[lidel]

There is no progress on getting classic request, and the build on i386 is broken since 0.12.

As noted in https://github.com/ipfs/kubo/issues/8688#issuecomment-1164285018, I am unable to invest more time into this time sink: it burns a disproportionate amount of time given relatively low user count (https://snapcraft.io/ipfs has ~3-4k weekly active users, while our browser extension alone has >60k).

My vote is to remove it – dev time can be better spent in other places.

We could nuke it like https://snapcraft.io/ipfs-cluster got removed in https://github.com/ipfs-cluster/ipfs-cluster/pull/649, or we could do this gently, by publishing a binary that prints "Snap is no longer supported, see https://docs.ipfs.tech/install/command-line/#linux for alternative installation method".

Don't feel strongly either way, would like to hear what others think.

---

General digression: I am using Linux myself (running Kubo in Docker). There is a long tail of Linux package managers. They all are great and terrible in their own unique ways and it is the best if people familiar with them spend time on producing packages.

Kubo produces prebuilt binaries as Docker images and a generic .tar.xz. There are also sources. IPFS Community can use either of them and repackage for their distribution.

I opened https://github.com/ipfs/kubo/pull/9239 to make it clear that everything other than Docker and https://dist.ipfs.tech/#kubo is unofficial.

[BigLep]

2022-09-02 maintainer conversation:

1. Core maintainers are not going to support Snap anymore.
2. We will push a binary that prints a message that says what the official distribution is
3. We'll point to the automation we have used in the past in case anyone wants to take it over.
4. We'll remove this from our release process.

[galargh]

Here's the plan for completing this issues:

• [x] Disconnect this repository from https://snapcraft.io/ipfs
• [x] Remove snapcraft.yml from this repository (https://github.com/ipfs/kubo/pull/9352)
• [x] Prepare a repository with snapcraft.yml which can produce a binary with information about Snap deprecation (https://github.com/galargh/kubo)
• [x] Wait for the Kubo v0.17.0 release
• [x] Connect https://github.com/galargh/kubo to https://snapcraft.io/ipfs
• [x] Wait for the "v0.17.0" release which only prints information about Snap deprecation to reach Snap
• [x] Disconnect https://github.com/galargh/kubo from https://snapcraft.io/ipfs

Here's the proposed deprecation text:

Kubo is not distributed through Snap anymore (https://github.com/ipfs/kubo/issues/8688).
Please download Kubo from https://dist.ipfs.tech/#kubo.

[galargh]

Kubo is no longer distributed through Snap.