Intent to package: Snaps are universal Linux packages

Dear maintainer(s),

Snaps are universal Linux packages that can be installed and run on many GNU+Linux distributions with ease. I've been following the Snapcrafters instructions and have built a working snapcraft recipe, you may try it by running the following commands after installing snapd:

sudo snap install --classic pre-commit
snap run pre-commit --help

I'm also looking forward to working with you to make the packaging work upstream (if you're interested). You may want to check out the documentation, registering a developer account on the Snap Store, and get in touch with us to transfer the work under your control.

Thanks for your time and attention.

:wave: hi! I don't know much about snap or what's involved in upstreaming or the maintenance cost associated with that -- can you help me understand that? Thanks!

Sure. Snaps is a new software distribution solution specifically designed for the upstream to distribute their products directly to the GNU/Linux users. It has the following advantages:

• Snaps can be installed and run on all GNU/Linux distributions that support Snapd, which is essentially those that have:
  • a relatively recent Go distribution (Snapd is written with Go)
  • a relatively new kernel with a subset of security features enabled
  • a working systemd installation (i.e. snaps are not available to systemd-less distros) There are many distros are already supported, refer Installing snapd - Documentation for snaps: Universal Linux packages for the list.
• Snaps bundle all of their runtime dependencies in itself, thus it eliminate the need to run pip in the user environment and risk polluting it with non-distro packages and is installed and removed cleanly with little leftovers. The publisher can be certain that the users are running their product with the exact same Python interpreter, packages, and underlying libraries thanks to the common base runtime provided by Ubuntu Core.
• Snaps are by default confined, which means that they can only access the resources they explicitly requested and are granted by either the Snap Store or the user. The user can be certain that a snap won't read their GnuPG/SSH private keys and uploading them somewhere on the internet.
• By incorporating the Snapcraft Build Service, the developer can set up automatic snap build and publish right from a GitHub repository, targeting i386/amd64/armhf/arm64/ppc64el/s390x architectures. A total of four release channels are provided so that the publisher can publish stable, candidate, beta and development snapshot builds simultaneously for the users to track from.

I've added your umich.edu e-mail address to the snap's collaborator list, by logging in with the Ubuntu One account associated with that address you can check out the snap's administration pages on https://snapcraft.io.

The upstreaming process involves:

1. Merging the snapcraft build recipe (a PR will be prepared when everything is settled)
2. Acquire a developer account on the Snap Store (which is essentially an Ubuntu One SSO account) and optionally, a Snapcraft Forum account.
3. Post a snap name transfer request under the store-requests topic category of the Snapcraft Forum, you'll have to mention either your snap account id listed in https://dashboard.snapcraft.io/dev/account/ or the associated e-mail address. You may check out this example: Transfer brook - store - snapcraft.io I can also make the post for you, in this case simply mention the aforementioned account details here.
4. After the name transfer is completed, you may start using the snapcraft build service to set up the automatic snap build and publishing from this repository, you may manage the snap's release details at the snap's releases page

The maintenance cost is relatively low for a non-GUI snap due to the lesser amount of technical difficulties to cope with comparing to ones with a GUI, however this snap is now packaged in classic confinement mode due to its requirement to execute arbituary commands which imposes additional challenges like potentially mixing incompatible host libraries with the one used in the snap when calling external commands (which causes crashes). I haven't really encounter it with pre-commit though, but there's a chance.

Oops.

I've added your umich.edu e-mail address to the snap's collaborator list, by logging in with the Ubuntu One account associated with that address you can check out the snap's administration pages on https://snapcraft.io.

I apparently forgot to do so, fixed, apologies.

cool, I accepted the invite, I'll take a closer look at this when i've got some free time :+1:

After discussing with the ~~Snapd~~ Snapcraft devs I'm fairly certain that the mixing library issue won't affect to pre-commit now.

I've posted a classic confinement request on the Snapcraft Forum, the snap can only be published to the Snap Store until its classic confinement usage is being vetted.

The classic confinement request for this snap is now granted by the Snap Store, and I've now published the latest stable release and the development snapshot builds to the snap's stable and edge channel. You may want to try it on various pre-commit enabled projects to verify it.

The installation instructions are now updated.

The snap is horribly out of date (https://snapcraft.io/pre-commit) - is this build service being used?

I never got around to working on this -- it might be best to sunset it entirely

What needs to be done to get it working?

@brlin-tw it might be best to disable the snap -- I'd rather not support it and it's very much out of date (and I purge snap myself on ubuntu)

I'm marked the snap as unlisted -- going to close this out