Request for alias and interfaces + autoconnection for Ritchie CLI

store-requests
1

Hello!

I am a Developer Advocate from the Ritchie CLI open-source project, which allows users to create, store, share, and run any kind of automation code snippets (written in interpreted and/or compiled programming languages), executing them through command line interfaces.

Our project has a key goal of providing great developer/user experience in the automation of all kinds of workflows. For that, we have a strong dependence on Docker, so that users can seamlessly build and run Formulas (our thin abstraction around automation code snippets) written in several popular programming languages without having to worry about local SDK & runtime installation/configuration/version switching. Our binary is named ‘rit’ and we have already packaged it for OpenSUSE and Arch Linux (AUR).

We are keen on the idea that Snap offers a formidable packaging and distribution model that can greatly help both project maintainers and users in having a great experience, allowing Ritchie CLI to be easily installed and used in all Snap-enabled distros (and especially in Ubuntu-derived ones).

In that context, I would like to kindly ask the Snapcraft team to review the following requests:

  1. An alias for ‘rit’, since that’s our binary and the way our users expect to and already interact with our application in manual installations or when using OpenSUSE and Arch Linux;
  2. Read/write access to $HOME/.rit, which is the directory owned by our application and used to store configuration files and the default workspace;
  3. Autoconnect to the Docker interface, since Docker – and a seamless use of it – is essential for our project to provide our key feature of seamless code builds/runs and the great dev/user experience we set out to achieve.

A possible alternative that could replace items 2 and 3 is the permission to run with ‘classic’ confinement – which, as I understand it, would allow us to interact with non-Snap versions of Docker, being highly useful for us. It would be very helpful to receive some guidance from Snapcraft architects/reviewers on this.

Given the fact our project is 100% open-source and has good documentation in both English and Brazilian Portuguese, we greatly expect that those requests may be granted, validating our choice of focusing on the Snap packaging & distribution model.

Thank you in advance for any review!

( ZupIT/ritchie-cli: Ritchie CLI is an open-source tool that allows to create, store and share any kind of automation, executing them through command lines, to run operations or start workflows :gear: :desktop_computer: :bulb: (github.com)

Details for ritchie-cli (snapcraft.io)

2

Bumping the thread since many people reached out to us with great interest in using the Snap package and we’re super anxious to get this going.

3

I’m +1 on the rit alias and r/w access to $HOME/.rit as the directory sounds like it’s clearly owned by the application.

Not super familiar with the docker interface, maybe @ijohnson can give some clues here?

  • Daniel
2 Likes
4

@dcominottim have a look at my example project of using the docker snap + docker interface : https://github.com/anonymouse64/docker-snap-usage-example

Typically, we grant connection of the docker interface but not auto-connection, but I have seen auto-connection been granted before for docker with vetting of the publisher. That’s something for the reviewers to decide however.

1 Like
5

Thanks a lot, @roadmr and @ijohnson!

Ah, I had found your example and used it as reference, @ijohnson. Was pretty useful!

I believe it’d be interesting to pursue the auto-connection with vetting of the publisher, but I am also pretty happy that the other 2 items seem to have been approved.

Please let me know about any other info/explanation I should provide, and thanks again for the help.

6

+1 from me for rit alias for ritchie-cli. +2 votes for, 0 votes against, granting the requested auto-alias rit.

+1 from me for auto-connect of personal-files with write access to $HOME/.rit since ritchie-cli is the clear owner of such directory. But could you please update your snap declaration to follow the standard as per The personal-files interface?

So instead of:

plugs:
access-files:
interface: personal-files
read:
- $HOME/.rit
write:
- $HOME/.rit

You should name the interface reference dot-rit instead of access-files. Also, write implies read so having write is enough. Since we have the enough votes, as soon as you update the declaration, we can proceed with granting this auto-connection request.

Before proceeding with the docker discussion, and since this is a very privileged interface, could you please update your snap description to mention the use of docker? I don’t see anything there yet.

1 Like
7

Ping @dcominottim - can you please provide the requested update to the snap?

1 Like
8

Hey @emitorino @alexmurray, thanks a lot for the instructions. I apologize for the delay – got caught up in some storms.

I’ve just uploaded version 2.11.3 to the beta channel with all the changes requested by @emitorino. The description from both the snapcraft.yml file and the listing details has also been changed to reflect the fact we interact with Docker.

9

Ah, a question: what exactly blocked the latest release to the Beta channel? Was it that the personal-files permission is still pending? The information I get on the e-mail isn’t very descriptive.

10

Yes this got blocked on the use of personal-files and the use of docker.

+2 votes for, 0 votes against, granting use-of and auto-connect of personal-files for richie-cli named dot-rit with write access to ~/.rit. This is now live.

11

+1 from me too for use-of but not auto-connect of docker for ritchie-cli.

12

Thanks for continuing the process, @alexmurray!

Which would be valid reasons to enable auto-connect of docker? Are there any Snaps that have such auto-connect today?

13

+1 from me too for use of but not auto-connect of docker for ritchie-cli. +2 votes for, 0 votes against. Granting use of docker to ritchie-cli. This is now live.

@dcominottim, since the docker interface is very privileged and grants device ownership to the snap, granting auto-connection is considered only when the snap is non-functional without it, and the process also involves publisher vetting like we do for classic snaps.

14

@dcominottim could you please either upload a new revision or request a manual review so the changes take effect? Thanks!