nvim has been granted classic confinement for its classification as an IDE editor
It would be nice it nvim-dev could be allowed to leverage classic confinement as well, for the same reasons. An additional snap is required so as to automate releases.
Can you please provide some more information as to what nvim-dev is? I assume it is a development version of nvim but for the sake of the Process for reviewing classic confinement snaps it would be good to have this publicly documented along with this request.
Also (assuming my summation above is correct) instead of publishing separate snaps as nvim and nvim-dev would it be more appropriate to use the existing risk levels provided by the store, and so publish to the edge channel for this development version and then promote this to stable as needed?
Your assumption is correct. It is the nightly build of neovim.
neovim has been published as you have suggested now for 2 years or more. This is not ideal though, because releases become a manual process. In our opinion, the ideal solution would be for the snapcraft build service to support a more robust API. There are several outstanding issues that have highlighted this same issue, but with little progress. For your reference:
With little to no attention to these issues, the only feasible solution for our use case is to one either cease providing nightly builds, or provide two different snaps. I have personally kept on eye on these various issues for awhile, and have been reluctant to implement the latter solution.
With little to no progress on the issues though, I honestly see no other path forward.
Internally build.snapcraft.io uses Launchpad snap recipes to do the actual building - and it is possible (but a bit more work) to configure a Launchpad project that mirrors the code from say a github repository, then configure multiple snap recipes to build from that repo, each of which publish to a different channel on the store.
As an example, I have configured the emacs-snap project on Launchpad (https://launchpad.net/emacs-snap) to mirror the code from Github, and then have created 2 snap recipes to build from the 2 different branches of that repo, one of which builds from the master branch publishes to the beta channel while the other builds from the snapshot branch of the repo and publishes to the edge channel. That way users who want the latest development version of emacs can consume the edge channel, whilst I can then use the beta, candidate and stable channels for doing release progression of the stable emacs releases.
Whilst it is a bit more cumbersome to setup, this kind of setup would allow your users to easily switch between say the development version and the stable version by just changing the channel which they are using for nvim.
@alexmurray I will give this an honest investigation and get back to you, thank you for all the details. Perhaps this information could be added to the documentation.
Okay, so one roadblock so far. The neovim team in launchpad is actually not controlled by any members of the neovim team, neither is the user neovim. Anyway we can get control of those namespaces?
Initially I would try contacting the owner of https://launchpad.net/neovim but you can always create a separate Launchpad project (e.g. called nvim to match the name of this snap).
We have sent several emails to the user in question. The project namespace would allow us to easily synchronize neovim repos, otherwise we will have to push.
Thank you for all your help, classic confinement will not be necessary for this snap. The channels will work. I will need to push the code to launchpad but that is easily attainable via GitHub actions. Thanks again.
It’s also possible to create a snap recipe in Launchpad that builds directly from GitHub without requiring mirroring, in the same sort of way that snapcraft.io does (in fact, snapcraft.io uses this interface under the hood); although this can currently only be set up using the API. https://launchpad.net/+apidoc/devel.html#snaps-new can be given a git_repository_url argument instead of the more usual git_repository argument.
1 Like
Oh TIL - thanks @cjwatson - it would be good to document this procedure somewhere - even in a reply to this thread 
Interesting. I see that API allows you to specify an “information_type” including “private”, “proprietary”, and “embargoed”… Does this mean we could work around the current requirement of the build service, as accessed via snapcraft.io and via `snpacraft remote-build, for the source code to be public during the build? It would certainly open an interesting use where currently the build service is unusable by companies such as Plex Inc. who want to retain control over their products’ source code.
It was this very problem that led me to investigate CI/CD to produce my Snapcraft container images:
Something like lp.snaps.new(owner=lp.me.self_link, name='name-of-recipe', git_repository_url='https://github.com/foo/bar', git_path='HEAD') is about the minimal form of it.
1 Like
You need to have access to a Launchpad project with a suitable sharing policy, which in turn requires having a commercial relationship of some kind with Canonical that causes us to set that up for you. But with those caveats, this is something that we can offer, yes.
1 Like
I am then removing this request from our classic confinement review queue. If you have any further question, please let us know!
Thanks!