Classic confinement for Idris 2


#1

Hey, I’d like to request classic confinement for idris2

Idris 2 is a successor to Idris 1, a dependently typed functional programming language. Idris 2 is currently in pre-alpha. A snap for Idris 2 would provide a hassle-free way for Idris users to stay up to date with the Idris 2 development.

Similar to existing snaps for language implementations (e.g. node, julia, go, etc.) idris2 needs classic confinement to be able to interact with arbitrary system libraries and tools.

Links:

Snap packaging: https://github.com/timsueberkrueb/idris2-snap.
Idris 2 (GitHub): https://github.com/edwinb/idris2
Idris (website): https://www.idris-lang.org/


#2

Is there a snap for Idris 1? If so, could you just use a track for the idris 1 snap instead?


#3

Nope, there is no snap for Idris 1, at least as far as I am aware of, yet.
I have already thought of creating one for Idris 1 as well, however I need to be confident that I can maintain both and I’ve decided that I will focus on Idris 2 only for now. Also Idris 1 is already available by several other means, while the only way to try out Idris 2 right now afaik is to build it yourself.

You’re right though, having a single idris snap with tracks for the different major versions would make a ton of sense, I haven’t thought about this option, yet! Would it be possible to delete the idris2 snap and create an idris snap with a default track for Idris 2 (for now)? It would probably also make sense to alias idris2 to the Idris snap with the 2.y.z track (is this possible?) because that’s probably what users (and other programs interacting with it) will expect.


#4

Unfortunately while snaps can be deleted, they cannot be renamed, so all current users of the idris2 snap would have to manually uninstall the idris2 snap and re-install the idris snap instead.

While I don’t think the work for default tracks is done yet to allow this, you could certainly request tracks for 2 right now and then publish Idris 2 to the latest (i.e. default) track as well as the 2 track and then if you find you have time go back and create another track for 1 and publish versions of 1 there as well.

You can’t rename snaps as I mentioned above, but you can create app aliases, so if you’re idris snap had an idris2 app that normally would be called as idris.idris2, you can request an alias for idris2 such that users would be able to call idris2 instead of idris.idris2.


#5

Thanks! One concern is what happens when users want to install both Idris 1 and Idris2, each of which are on a different track of the same idris snap. I have seen https://ubuntu.com/blog/parallel-installs-test-and-run-multiple-instances-of-snap but does this apply to different tracks? Also users would have to name e.g. the Idris 2 instance idris_2 rather than idris2 which again could be confusing if other software expect the executable to be named idris2, right?

so all current users of the idris2 snap

Since the snap is currently in the queue for classic confinement, it doesn’t have any users, yet, so that’s not a problem :slight_smile:


#6

Yes you can have parallel installs of snaps on different tracks, however currently the parallel install feature is limited to classic snaps. We are actively working on supporting classic snaps with parallel installs however…

This could also be handled by aliases, but AFAIK I don’t think you would be able to have the aliases for a parallel installed snap be handled through declarations. What you would probably do in this case (assuming that parallel installs for classic snaps lands soon enough for your use case) is something like this:

snap install idris --track=1
snap install idris_2 --track=2
snap alias idris_2.idris2 idris2

which is manually creating the alias for the parallel installed snap.


#7

Yeah that would work.
Is it possible to use build.snapcraft.io with different tracks (e.g. one repo for the 1.X track, one for the latest/2.x track)?


#8

Unfortunately not, you need to use launchpad to build different tracks. However build.snapcraft.io is just a convenient wrapper to launchpad so the builds will run the same, just you need to setup the builds with a different UI and building on every commit requires pushing to the launchpad clone in addition to pushing to GitHub. Alternatively you can have a git repo on launchpad sync with GitHub which happens I think every 6 hours or something like that.


#9

The requirements for classic are understood (programming language category). @advocacy, can you perform the vetting?