Added support for snaps

[ivan770]

Closes #2171

[ivan770]

There are a few things that left to be done:

1. I registered the name helix, but since I'm not in the org nor I'm an active maintainer I'll transfer it;
2. Someone who receives transferred name will have to request classic snap approval on the forum. This step is required, since currently snaps do not support interop with external environment while being inside confinement. The whole process is described here;
3. After that, we can use build.snapcraft.io to automatically build and publish new versions;

[the-mikedavis]

Sorry for the delay on this. Is there any way to package for snaps without needing anything "official" or from a maintainer? We're happy to answer questions and such but we prefer to have as much packaging done by community effort as possible - otherwise our personal time faces death by a million package managers 😄

snaps do not support interop with external environment while being inside confinement

Is confinement part of the build or runtime lifecycle? When building from releases, we provide a helix-$VERSION-source.tar.xz artifact in the GitHub Releases page which has all of the tree-sitter grammar repositories pre-downloaded. If you use that, the build process doesn't need to reach out over the network at all. Nixpkgs (i.e. the Nix package collection which builds in network isolation) uses this for example and it ends up being a very boring rust project build. That can solve build isolation and I don't think helix really needs runtime network access - it essentially shells out to git (and maybe curl in the future) for that stuff.

[ivan770]

Sorry for the delay on this. Is there any way to package for snaps without needing anything "official" or from a maintainer? We're happy to answer questions and such but we prefer to have as much packaging done by community effort as possible - otherwise our personal time faces death by a million package managers 😄

I think it's possible for me to publish a snap package, I'll try to handle all the publishing process then.

Is confinement part of the build or runtime lifecycle? When building from releases, we provide a helix-$VERSION-source.tar.xz artifact in the GitHub Releases page which has all of the tree-sitter grammar repositories pre-downloaded. If you use that, the build process doesn't need to reach out over the network at all. Nixpkgs (i.e. the Nix package collection which builds in network isolation) uses this for example and it ends up being a very boring rust project build. That can solve build isolation and I don't think helix really needs runtime network access - it essentially shells out to git (and maybe curl in the future) for that stuff.

Confinement is part of a runtime lifecycle, the build part is already solved out by this PR. The key feature of snaps is that they provide runtime application isolation with granular permission configuration, but since Helix is (sorta) an IDE, I'll request a permission on Snapcraft forums to publish a package without permission isolation.

[the-mikedavis]

Awesome, thank you!

Looking more into confinement, I think we do need classic mode so that we can call language server binaries 👍

Naively, this snapcraft.yaml looks pretty good although I'm not too familiar with the plugins or schema. Could you rebase onto a more recent master and unmark this as a draft when it's ready? We changed up some of the actions a while back so there are some unmet required checks for the branch protection rules that will need to run to merge

[pascalkuthe]

Closing since there is a helix snap package now, see https://github.com/helix-editor/helix/issues/7545