[WIP] chore: add snapcraft.yml for first deployment of snap

[JosephGoulden]

This is the config file for the snap https://snapcraft.io/grin

Can we update the versions in here when we release? There is tool (snapcraft) for building and publishing the snap based on this config. I can run manually for now, but it should be done in the CI pipeline.

[antiochp]

Are we committing to using snap here? I'm not familiar with the current state of the art in packaging systems right now. Is it used within the rust community at all?

There is every likelihood that snap is the right direction to go in here but we should be reasonably sure before adding config files.

[JosephGoulden]

I wouldn't say its a commitment as such. Snap is just one of several ways of distributing software on Linux, it's language agnostic. I would assume we want to make it as easy as possible for anyone to start using grin. At the moment I'm using Ubuntu desktop and the first place I look for software to install is Snap. But others might use https://www.flatpak.org for example. So we probably want to put Grin in there as well. There is the overhead of maintenance and publishing each release so we should only pick channels that we consider worthwhile.

[antiochp]

Question - If we are packaging both grin and grin-wallet is it worth considering moving this snap yml file out into a separate repo?
It might be overkill but not 100% sure we want to add dependencies here in this repo between grin and grin-wallet.

[lehnberg]

I agree - it makes sense to me as well to move grin-wallet into it's own yml under the grin-wallet repo.

In relation to the discussion above - what are the pros and cons with snap compared to flatpack or AppImage? I don't know much about snap, but I believe one of the criticisms/concerns for the project is that server side is kept closed source and that it is closely affiliated with the Canonical company.

I agree with @JosephGoulden - supporting all three of these, alongside yum and apt, plus home-brew and choco, and it starts becoming quite an overhead to maintain. Or maybe it's not, and it's actually worthwhile?

It might make sense to do some research and bring forward a holistic proposal. Another (naive) question - are we exposing ourselves to any potential security concerns by using these distribution channels?

Would anyone be up for doing a bit of evaluation, exploring pros and cons with different approaches?

[JosephGoulden]

There are two reasons I put wallet and node apps together in the same yml/snap. First is that it was easier to get them working this way. As snaps run in containers they have their own file system and home dir, and are not allowed to share this with other snaps. As grin and grin_wallet share .grin dir it was simpler to put them in the same snap, or we'd have to maybe make the .grin location configurable or do something more sophisticated with snap. I just wanted to get something working - MVP.
But then the second reason is its just simpler for users. If someone wants to use Grin they will need both apps, so why not package them together, they can install with one command.

Happy to try this in a separate repo. I'd like to have a go at automating the publishing of the snap when we release. Was thinking of looking at GitHub actions (although I know we use Azure now so might be better to stick with that). The automation aspect is perhaps my main consideration in looking at where this should go. I'd like to think if we automate them all the maintenance will be manageable and worthwhile.
Yes there are security concerns of course, I'd like to make it easily verifiable that whats installed is correct, the automation pipeline helps with that.
If we do not claim any of the distribution channels for some reason, that just leaves them open for someone else to use, which is potentially a more severe security concern.

[quentinlesceller]

I'd advocate to create a packaging repo just like bitcoin-core. See https://github.com/bitcoin-core/packaging

[lehnberg]

@JosephGoulden we discussed this in today's dev meeting and there seemed to be general support for having a separate packaging repo to handle all package managers as was suggested above.

@quentinlesceller also created this meta issue for automation. #3140

Would be great to have you onboard if you'd like to help with figuring all this out!

[JosephGoulden]

Cool, yeah happy to help out. Thinking automation isn't high priority right now given releasing new versions does not happen very often, but it's something we can iterate on in the background.

Will close this PR in favour of a new one for the packaging repo.