Hello!
Yarn is a package manager for nodejs. During the snapcraft rally we packaged it, and the last remaining issue has now been solved. Now to release it to edge and test it further, we need to get the approval to use classic.
The node packages can define arbitrary tasks to run during installation. So yarn will need to execute external commands to be useful.
pura vida
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
and,
sudo snap install yarn --classic
yarn install npmIā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!
Based on @niemeyerās comments in Classic confinement for `node` snap, this snap is allowed to use classic and the store has been updated accordingly.
Great!
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 npm and 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.
Related:
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 node, npm and yarn binaries. With the yarn alias, the user will snap install node --classic and receive node, npm, 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 aliases, auto-connections and tracks, not that installing yarn would get you node, just that the node snap would export a top-level yarn command.
@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 yarn command?
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.
Cheers!
@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:
npm alias sorted out so we can properly export that comment from therenpm we 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.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?