ping? Can somebody please confirm my assessment that this should be classic?
In the past we have not approved installer snaps since the snap is installing something that is not vetted from somewhere that is not vetted and putting it on the system so the user can run it unconfined. The snap becomes a potential gateway for malware.
Is the snap meant to put the fetched binaries into other snap’s directories (and therefore the fetched content runs confined?).
Regardless of the answer to that, I’d like to get a definitive answer on this sort of snap. @niemeyer - can you comment? If we want to accept these sort of snaps, are there guidelines we can follow to help protect users and the store’s reputation?
If @elopio is publishing the snap, doesn’t that side step the issue?
If we ultimately transferred control to Facebook, I feel it would be appropriate for them to publish this as a classic snap. Given the nature of yarn it cannot function strictly confined. It is an understatement to say it is extrememly popular software already trusted in its current form.
How is different from vscode or atom where plugins can be installed from a store as would be yarn installing from a language store?
@sergiusens - maybe it isn’t different, but maybe it is (that is what I’d like to have a formal statement on). My understanding of editors downloading plugins is that they are for that editor to use. If the snap is classic, yes, that is implicit trust in the plugin, but if strict, then that code runs within the confinement of the editor (which would be ok in my mind). For a games installer, it is plopping code on the system to run unconfined so there is implicit trust in that code. For yarn, it is downloading code to be used by nodejs, which may or may not be confined (if confined, ok in my mind, but if not then implicit trust in the code).
To @Evan’s point-- @elopio is vetted as a publisher, yes, and I have no issue granting classic to the snap for him. The question isn’t about the snap though; it is about the code that this snap plops on the system for use outside of confinement which @elopio hasn’t touched.
I consider it part of my role as gatekeeper to protect users and preserve the store’s reputation, so in that spirit I am raising these points for an architect to rule on so we can have clear direction going forward (for plugins, for language packages, for game/binary installers, …).
Your points are all valid, but I don’t see a difference between
sudo snap install go --classic go get github.com/snapcore/snapd/cmd/snap
sudo snap install yarn --classic yarn install npm
I’m not as familiar with node and yarn but your point seems valid for yarn. I’d like to hear an architect’s thoughts on the larger issue before granting classic for this specific use case. Thanks!
@niemeyer - as an architect, can you give guidance on my question regarding ‘installer snaps’? Thanks!
We will start testing and report here of any unexpected effects of classic.
Hey @elopio, I’ve got the
node snap publishing and was planning on asking for aliasing for both
yarn top-level executables from it too. I’ve only now seen that you’re already publishing one but would consider giving this up to allow for an alias instead?
See source @
https://github.com/nodesource/distributions/tree/master/snap — we’re currently doing ‘edge’ but will also be doing release versions for all active release lines. You can see in there that we have Yarn built into the process so
node.yarn is already available and ready to alias. Each new release will get the latest Yarn release shipped in it and we’ll be able to coordinate with the Yarn team to ensure appropriate compatibility where necessary similar to what we do currently with npm as it’s shipped in the Node source (although there are a lot fewer compatibility problems between Node and Yarn as there are between Node and npm).
I’ve been speaking to the Yarn team about this as well and the reasons that we think that both npm and Yarn should come out of the same snap relate to the difference between the version of Node that is used to run npm/Yarn compared to the version of Node that is used to execute that same application. When you
install with both Yarn and npm, they use the current Node version to determine how to assemble the packages. One problem area is the compilation of C/C++ add-ons. It has to download and compile against the correct set of headers and produce an ABI-compatible binary. Currently Node 4, 6, 8, 9 + have compatible ABIs and API’s within the major-version, but break across these release lines so add-ons have to be recompiled. In addition, there are a lot of
postinstall scripts across Node packages that both npm & Yarn will execute as part of installation and a lot of these also rely on the Node version to get a particular job done. Most common of these is to download pre-compiled add-ons that match the correct ABI for the current version of Node.
Hence the dilemma, since we’re unable to pin the version of Node shipped in the
yarn snap to the version of Node shipped in a
node snap that a user might use in combination. The ideal is to ship everything in one and expose it all.
FYI also we are also making plans to ship Yarn in our Linux distribution packages (
https://github.com/nodesource/distributions, the most popular source of Node on Linux aside from native distro repositories) along with npm, so this would be a similar move.
So, the idea would be that if you run
snap install yarn, you get the node snap you are preparing instead?
To be clear, the nodesource produced node snap should have
yarn binaries. With the
yarn alias, the user will
snap install node --classic and receive
yarn commands. If the upstream Yarn developers which to deploy a yarn snap, then they could do that too. If a user installs yarn and node snaps, the yarn snap would take the yarn name from node on that install. AIUI.
@elopio “alias” in the sense that it’s used here Process for reviewing aliases, auto-connections and track requests, not that installing
yarn would get you
node, just that the
node snap would export a top-level
@popey is this is the way it works now? There’s nothing preventing a snap with the same name as a top-level alias of another snap existing in the store at the same time? How does prioritisation work with this, is it always the case that the
yarn snap would get the
yarn command even if it’s installed before the
node snap that exports a
I was working under the assumption that a top-level alias for one package would preclude a snap from existing in the store with that alias. If this is not the case then I guess it’s not a blocker for us to request a
yarn alias for the
node package and it then becomes a matter of education and trouble-shooting for users that run into the kinds of problems I’ve mentioned above. My preference would still be for there to be a single
yarn available from the store and currently I have the Yarn team agreeing to coordinate with us to manage it through the
node snap since we both agree that it makes sense to bundle it together.
@rvagg yes, this registered snap called yarn is not a blocker for your alias. So go ahead and request it.
What seems to me is that if we have a node snap that includes a yarn command, and a yarn snap that includes a node command, both snaps will have the same contents, just inverted names and aliases. So let’s work together on this
For now, I will leave this yarn snap in edge so it’s not discoverable in the store. We can focus on testing your node+npm+yarn snap, and then figure out if we need one called yarn in stable too.
Is there something I can do to help you with your snap?
@elopio sounds like a plan. Currently the
node snap being published daily to edge, pulling in the Node.js nightly builds, and it’s working really nicely. The next steps that I have are:
- Get the
npmalias sorted out so we can properly export that comment from there
- Once we’re happy that it’s working properly with
npmwe have some testing to do on Yarn and I’ll get the Yarn team up to speed on this so they can test it too and make sure it works according to their expectations.
- Tie in our release build process so we can get full release builds into the store. This is going to require getting “tracks” approved so we can publish them as 4, 6, 8, 9 to correspond with the current supported Node.js release lines.
Getting progress on Requesting `npm` alias for `node` package would be the next piece then.
Note that soon snaps will be visible even if they are in edge.
Interesting. Will devmode snaps still be filtered?
Good question… we did not discuss these. It does sound sensible to leave those out, as those are effectively wide open snaps that require typing out a flag in the command line that only makes sense for development. We’ll need a flag that tells whether the snap has any non-devmode published revisions.