Go-ipfs: Outdated go-ipfs on the Snap Store breaks IPFS Desktop onboarding experience

Created on 29 Apr 2020  Â·  17Comments  Â·  Source: ipfs/go-ipfs

Context:

Problem:

  • go-ipfs is late on snap.
  • Hence, following instructions from Readme will install an outdated version.
  • Worst, it will install a version which is incompatible with IPFS Desktop. IPFS Desktop is supposed to be the easy way in IPFS-land (or rather IPFS outer-space... ).

Proposed solution:

  1. Manually bump go-ipfs on snapstore to 0.5.0
  2. Include publishing go-ipfs to snapstore to the regular release process

Alternative, sad solutions:

  • remove go-ipfs from snapstore
  • or remove IPFS Desktop from snapstore.

Since IPFS Desktop is supposed to be the onboarding app for naive users, being able to install both it and IPFS via the default package manager is handy.

@elopio for the snap update,
@lidel for the IPFS Desktop side

Related: https://github.com/ipfs/go-ipfs/issues/5423

kinenhancement

Most helpful comment

0.6 is available from the stable snap channel

ubuntu@reasonable-walleye:~$ ipfs version

Command 'ipfs' not found, did you mean:

  command 'ipcs' from deb util-linux
  command 'ipfm' from deb ipfm
  command 'ips' from deb ips

Try: sudo apt install <deb name>

ubuntu@reasonable-walleye:~$ sudo snap install ipfs
2020-07-15T15:09:41+01:00 INFO Waiting for restart...
ipfs 0.6.0-d6e036a88 from Leo Arias (elopio) installed
ubuntu@reasonable-walleye:~$ ipfs version
ipfs version 0.6.0
ubuntu@reasonable-walleye:~$ ipfs daemon --init
Initializing daemon...
go-ipfs version: 0.6.0-d6e036a88
Repo version: 10
System version: amd64/linux
Golang version: go1.14.4
initializing IPFS node at /home/ubuntu/snap/ipfs/common
generating 2048-bit RSA keypair...done
peer identity: QmTxa2VSCsXeXd4cY8eUu5665ZMjJM59TLYgdUeQy9ffLC
to get started, enter:

    ipfs cat /ipfs/QmQPeNsJPyVWPFDVHb77w8G42Fvo15z4bG2X8D2GhfbSXc/readme

Swarm listening on /ip4/127.0.0.1/tcp/4001
Swarm listening on /ip4/127.0.0.1/udp/4001/quic
Swarm listening on /ip4/192.168.64.7/tcp/4001
Swarm listening on /ip4/192.168.64.7/udp/4001/quic
Swarm listening on /ip6/::1/tcp/4001
Swarm listening on /ip6/::1/udp/4001/quic
Swarm listening on /p2p-circuit
Swarm announcing /ip4/127.0.0.1/tcp/4001
Swarm announcing /ip4/127.0.0.1/udp/4001/quic
Swarm announcing /ip4/192.168.64.7/tcp/4001
Swarm announcing /ip4/192.168.64.7/udp/4001/quic
Swarm announcing /ip4/91.135.10.211/tcp/46173
Swarm announcing /ip6/::1/tcp/4001
Swarm announcing /ip6/::1/udp/4001/quic
API server listening on /ip4/127.0.0.1/tcp/5001
WebUI: http://127.0.0.1:5001/webui
Gateway (readonly) server listening on /ip4/127.0.0.1/tcp/8080
Daemon is ready

All 17 comments

Wow, that's _really_ out of date. We need to add snap to our release checklist, apparently.

Can we even maintain it ourselves (do we have access)? I think @elopio stopped a while ago. I did not have a very good experience with cluster and eventually decided to not sink more time with snaps. I think the maintainers can see a download count for their packages though.

The quickest is to update the Readme and remove snaps while figuring out the mess. Afaik it is the only place where this installation method is suggested.

We already maintain ipfs-desktop snap, so I vote for adding it to release checklist.

If @elopio checks github notifications: please add me ("lidel" on snapcraft) as maintainer, I'll try to figure it out.
In case he does not, I filled a claim to transfer ipfs to us (pointed we already keep official ipfs-desktop snap up to date)

Hello IPFS friends. I've added @lidel as a maintainer. Let me know if you need something else.

Thank you @elopio!

Too late for me to tackle this today, but some quick notes about next steps here:

  • https://snapcraft.io/docs/go-applications

    • sounds like adding snapcraft.yaml to the repo and testing manually-built Snap on local machine would be first step

    • when working as expected, open PR to include snapcraft.yaml in the repo

  • https://snapcraft.io/build

    • when we are happy with snapcraft.yaml and it is merged to master we can enable automatic builds using the above service

    • Snap supports multiple channels: https://snapcraft.io/docs/channels

    • stable channel would have release versions

    • edge could be built for every change merged to master



      • i think we could even build branches and make sudo snap switch --channel=edge/branch-name ipfs possible


      • iiuc "branch channels" on snap are closed after 30 days of inactivity, so it could be then replaced with regular edge – TBD if we are interested in this



Hey @lidel - is someone tracking this on the desktop team? Can we at least get a read on download count so we can prioritize this vs other work to help folks update?

@momack2 I am afraid its on my plate, rest of the GUI team is macOS/Windows.

Metrics for package published at https://snapcraft.io/ipfs are below.
Bit over 1k of mostly Ubuntu users are stuck with this ancient version.

Let me know if I should prioritize this (I don't have any experience with Snap but – cue optimistic theme – it should not take more than 1 day to sort this out).

2020-05-26--00-51-24

2020-05-26--00-55-48
2020-05-26--00-55-21

@andrew any chance you could take this over?

@Stebalien I can take a look, I guess I can just create an ubuntu vm and try to set it up there

@lidel you should be able to set up automatic builds/releases in this github repo (with the proper permissions on snapcraft.io) by creating a snapcraft.yml file

Strongly agree with @fubuloubu, (and everyone else on this thread) this seems like a chore that should be automated & traceable, not reliant on individuals. @andrew if you haven't started on this already, I'll take a look at automating it.

We have an updated snapcraft.yaml and documentation over here: https://github.com/ipfs-shipyard/ipfs-snap - I needed to work through all the steps to get my head around building snaps. It's working and i've published a docker image for testing it out. I'm also able to build it reliably directly via snapcraft on a mac now too, which is nice.

Notable changes

  • fixes an issue that where each update would require the user to re-init a new repo and lose there pins and peerId, by setting $IPFS_PATH to be the $SNAP_USER_COMMON dir. (as raised in https://github.com/elopio/ipfs-snap/issues/12)

    • removes the home plug as it's using the provided snap common dir for the repo

    • sets the snap version string from the output of ipfs version --commit

    • uses the snap go plugin to set the build environment.

The next steps are

  • [ ] Get some eyes and feedback on https://github.com/ipfs-shipyard/ipfs-snap
  • [x] Temporarily connect https://github.com/ipfs-shipyard/ipfs-snap as the source repo for our snap builds and manually trigger build on the snapstore infra for go-ipfs 0.5.1 and 0.6 as originally proposed by @bertrandfalguiere (this lets us use their infra to build out for arm64, i386, etc (see: https://github.com/elopio/ipfs-snap/issues/2 )
  • [x] PR the snapcraft.yaml here, and if accepted, set ipfs/go-ipfs as the souce repo

@elopio I'd love to know if you have any thoughts/concerns/recommendations on https://github.com/ipfs-shipyard/ipfs-snap as it's derived from your work in https://github.com/elopio/ipfs-snap

Get some eyes and feedback on https://github.com/ipfs-shipyard/ipfs-snap

@rvagg if you have some time to look at this it would be appreciated.

of note, it took a few goes for me to get this working locally, and I was initially drifting towards the "sad option" of removing ipfs from the snap store, as we dont have much bandwidth to maintain this, but I'm happy that what is here works and I understand it suffciently to maintain it. Also, even if we wanted to pull the ipfs snap from the store, it is a low friction publishing process, so would likely get published there again, and requires some ci chops to keep it working from a third part repo, so adopting it seems like the best outcome. I am happy to keep an eye on it and review if it causes trouble.

The flow I imaging is we let the snapstore build our snaps for us so the edge channel always has the latest from master, and then promote a build to the stable channel when we cut a release. This could be automated in CI, but it requires putting more complexity in our circle config that I dont think is justified yet. Promoting a build to the stable channel is trivial via the snapstore UI, I can take that on for now. I think the blocker previously has been not knowing the process, and not having access to the account.

Hey, nice work, I'm so happy you are taking this over.

I'm trying to take some vacations (and failing, of course, that's why I'm here :disappointed: ) So I will not have time to test it soon, I'm sorry.
Just one quick comment: I think the home plug was there so you could add to IPFS files you are storing in your home directory. With the current configuration, I think you would be able to add only the things in /media.

Thanks for the tip! You are right, I get a permission error when trying to add to ipfs from my home dir. Will revert that.

0.6 is available from the stable snap channel

ubuntu@reasonable-walleye:~$ ipfs version

Command 'ipfs' not found, did you mean:

  command 'ipcs' from deb util-linux
  command 'ipfm' from deb ipfm
  command 'ips' from deb ips

Try: sudo apt install <deb name>

ubuntu@reasonable-walleye:~$ sudo snap install ipfs
2020-07-15T15:09:41+01:00 INFO Waiting for restart...
ipfs 0.6.0-d6e036a88 from Leo Arias (elopio) installed
ubuntu@reasonable-walleye:~$ ipfs version
ipfs version 0.6.0
ubuntu@reasonable-walleye:~$ ipfs daemon --init
Initializing daemon...
go-ipfs version: 0.6.0-d6e036a88
Repo version: 10
System version: amd64/linux
Golang version: go1.14.4
initializing IPFS node at /home/ubuntu/snap/ipfs/common
generating 2048-bit RSA keypair...done
peer identity: QmTxa2VSCsXeXd4cY8eUu5665ZMjJM59TLYgdUeQy9ffLC
to get started, enter:

    ipfs cat /ipfs/QmQPeNsJPyVWPFDVHb77w8G42Fvo15z4bG2X8D2GhfbSXc/readme

Swarm listening on /ip4/127.0.0.1/tcp/4001
Swarm listening on /ip4/127.0.0.1/udp/4001/quic
Swarm listening on /ip4/192.168.64.7/tcp/4001
Swarm listening on /ip4/192.168.64.7/udp/4001/quic
Swarm listening on /ip6/::1/tcp/4001
Swarm listening on /ip6/::1/udp/4001/quic
Swarm listening on /p2p-circuit
Swarm announcing /ip4/127.0.0.1/tcp/4001
Swarm announcing /ip4/127.0.0.1/udp/4001/quic
Swarm announcing /ip4/192.168.64.7/tcp/4001
Swarm announcing /ip4/192.168.64.7/udp/4001/quic
Swarm announcing /ip4/91.135.10.211/tcp/46173
Swarm announcing /ip6/::1/tcp/4001
Swarm announcing /ip6/::1/udp/4001/quic
API server listening on /ip4/127.0.0.1/tcp/5001
WebUI: http://127.0.0.1:5001/webui
Gateway (readonly) server listening on /ip4/127.0.0.1/tcp/8080
Daemon is ready
Was this page helpful?
0 / 5 - 0 ratings

Related issues

magik6k picture magik6k  Â·  3Comments

Jorropo picture Jorropo  Â·  3Comments

kallisti5 picture kallisti5  Â·  3Comments

JesseWeinstein picture JesseWeinstein  Â·  4Comments

daviddias picture daviddias  Â·  3Comments