[pulsar-next] Ensure the canary release channel's pulsar and ppm always work correctly

[savetheclocktower]

The “canary” channel — which I sometimes call “PulsarNext” because I can't decide on a name — is something we'll have to do for a while so that people can run the latest-Electron version alongside the regular Pulsar version. This roughly corresponds to Atom's concept of a separate “release channel”; Atom had beta and nightly release channels.

To make this possible, yarn dist --next (the --next flag is new) will tell the repo to build a different channel of Pulsar — complete with a different name, a different storage path (for IndexedDB and other data), and a different ATOM_HOME (since two versions of Pulsar with different underlying Electron versions shouldn't share ~/.pulsar). The pulsar and ppm executables should have different names — e.g., pulsar-next and ppm-next.

Perhaps most challenging is the fact that ppm-next will need to point to the PulsarNext app's ATOM_HOME. For instance, ppm-next should not list the packages that are installed into ~/.pulsar; it should default to listing the packages installed into ~/.pulsar-next.

Requirements:

• Alias pulsar and ppm to (e.g.) pulsar-next and ppm-next so they don't get in the way
• Make it impossible for pulsar-next to launch Pulsar
• Make it impossible for pulsar to launch PulsarNext
• Make it difficult for ppm-next to install things in the wrong ATOM_HOME folder and vice versa
  • we may want to let the user override this with ATOM_HOME, but we might also want to introduce some sort of “are you sure”? speed bump here.
• Ensure ppm-next rebuild foo rebuilds package foo…
  • …in the correct location
  • …against the correct version of Electron
  • …both in the CLI and in the GUI (via the builtin incompatible-packages package)

[savetheclocktower]

This is almost 100% done:

• At build time pulsar.sh is copied to the resources folder and named either pulsar or pulsar-next depending on the chosen release channel
• That script also exports an ATOM_BASE_NAME variable that the editor can read; that's how the editor itself knows which release channel it is (at least when launched via CLI)
• The “Install Shell Commands” command needs to know the path of the script it's symlinking, so it first tries to read ATOM_BASE_NAME, then falls back to checking for the presence of either pulsar.sh or pulsar-next.sh (or .cmd for Windows) in the resources directory
• pulsar.sh is symlinked to pulsar; pulsar-next.sh is symlinked to pulsar-next (whichever of the two is present)
• If the user defines an explicit ATOM_HOME, it's respected; otherwise the shell script picks the correct ATOM_HOME for the user's release channel and exports it so the editor can read it

Things left to solve:

• What about when the editor isn't launched via CLI?
  • I should define the release channel in a place that can be read by the app no matter how it's launched
• What about when ppm is run in the terminal? How does it know that it's a version of ppm that operates on a version of Pulsar under a different release channel? (In other words, how does it know it's supposed to install things in ~/.pulsar-next rather than ~/.pulsar?
  • I might do what we did with Pulsar here and rename the binary to ppm-next at build time
  • Failing that, it could check for some metadata in its directory (this is what I'm doing now, but it feels hacky)