Experiment: Redirect `-p`/`--package` to `ppm` via `pulsar.sh`…

[savetheclocktower]

This one is in draft mode until I can get some Linux testers.

Identify the Bug

There are a handful of issues with pulsar.sh on macOS and Linux; they’re largely covered in #1053:

• There’s no reason that -p/--package need to get all the way to Pulsar before they’re handled. We should redirect them to ppm in pulsar.sh.
• Error messages generated by pulsar go to stdout instead of stderr.
• On Linux, pulsar.sh hard-codes an assumed install location — presumably the place it resides when installed via rpm or deb. If a user has downloaded the tar.gz version, pulsar.sh will fail to find their installation automatically, even though pulsar.sh lives within that directory.

Description of the Change

• All error messages now go to stdout.
• When -p or --package is present among the arguments, pulsar.sh will now handle them exactly how Pulsar itself does: by ignoring all arguments before -p/--package, then collecting all arguments after -p/--package and calling ppm instead of Pulsar.
• Linux now has similar detection logic to that of macOS; if pulsar.sh is invoked from a symlink, it should now be able to determine its real location, then traverse upward to find a binary called pulsar.
• The user should be able to supersede all this location logic (on either platform) by specifying the PULSAR_PATH environment variable manually.
• Like #1054, this will also fix the fact that pulsar -p --version prints the version information for Pulsar instead of ppm.

Alternate Designs

We already do the main alternative to handling --package in pulsar.sh — and we should keep it as a fallback.

Possible Drawbacks

Bash scripts are a bit harder to write and don’t have a great testing situation, so I’d love to get field reports on how well this works on Linux. I was able to test the macOS parts on my local machine, but on Linux I’m mainly flying blind.

Verification Process

• Verify all these commands produce the same output:
  • pulsar --package --version
  • pulsar -p -v
  • ppm --version
  • pulsar --wait --package --version (testing that any arguments before --package are ignored
• Verify these commands produce the same output
  • pulsar --package list
  • pulsar -p list
  • ppm list
  • pulsar -v --package list
• Verify that commands which don't use --package/-p behave like they always did:
  • pulsar .
  • pulsar --dev .
  • pulsar --wait foo.js
  • pulsar --test spec/*-spec.js

Extra testing for Linux:

• Download the tar.gz distribution of Pulsar, extract it somewhere, then symlink its ./resources/pulsar.sh to (e.g.) pulsar-test someplace on your path, like /usr/local/bin. Verify that pulsar-test passes all the manual tests described above.

Release Notes

• Improved the command-line pulsar script’s ability to find the user’s Pulsar installation location on Linux.
• On macOS and Linux, pulsar -p now invokes ppm without having to launch Pulsar itself.

[savetheclocktower]

OK, I grabbed a lightweight Ubuntu-flavored distro and did some testing on VirtualBox. The script needed some tweaks because of typos and my Bash naïvete, but now it works solidly on tar.gz distributions of Pulsar for Linux.

The same logic that works properly for Pulsar at an arbitrary location on disk will also work for Pulsar installed at the standard /opt/Pulsar path of the RPM and DEB packages — but if, somehow, it doesn't, then we'll still check a hard-coded /opt/Pulsar path to be safe.

I think the code path for CI is silly, but I want to understand it better before I take it out.

AppImage is another ball of wax and will have to be tackled in a separate PR.

[savetheclocktower]

Failing editor test is the one that's known to be flaky. Not going to bother with re-running it for now.

[DeeDeeG]

Re-running CI so I have some binaries to test. (Old ones are expired and deleted by GitHub Actions due to the passage of time.)

CI is passing as of before my doing so, for the record.

[DeeDeeG]

I'm not sure if pulsar.sh was ever expected to work for .tar.gz bundles, as it's just as easy to call the pulsar binary directly by absolute (full) path as the launcher, and it basically works fine.

(Come to think of it: Why do we really need the .sh launcher??? I have always found directly launching the actual Electron binary just as satisfactory to my needs as the launcher. I don't have a lot of love for mysterious "don't think about it too hard" kinds of complexity...)

So, if that works, I consider it above and beyond.

[DeeDeeG]

Sorry for the delay in review.

Your work on testing this has been thorough enough I am just about temped to round it up to being all the review this PR needs. Will try to make time to properly review it to whatever extent it still needs it beyond what you've already done to establish its bona fides.

[savetheclocktower]

I'm not sure if pulsar.sh was ever expected to work for .tar.gz bundles, as it's just as easy to call the pulsar binary directly by absolute (full) path as the launcher, and it basically works fine.

(Come to think of it: Why do we really need the .sh launcher??? I have always found directly launching the actual Electron binary just as satisfactory to my needs as the launcher. I don't have a lot of love for mysterious "don't think about it too hard" kinds of complexity...)

So, if that works, I consider it above and beyond.

I wouldn't quite say it works fine. It logs some main process output to the console. Some features don't work, like --wait. (Those last two, taken together, make it impossible to use Pulsar as a Git editor for commit messages, interactive rebases, etc.) Having the wrapper allowed us to fix a major encoding headache on Windows and it allows us to redirect --package to PPM on all platforms without making people wait for Electron to start up.

The goal is to be able to give people commands to run (in documentation, in Discord, etc.) and know they'll basically work the same everywhere, instead of “how did you install this? because if it was X, you'll run this, but if it's Y, you'll run this…”

This is also a prerequisite for AppImage users being able to invoke Pulsar properly (#1069). ~~Right now it doesn't work at all because it tries to look for an executable in a fixed location on disk.~~ Scratch that; right now the AppImage runs its own script that invokes the executable directly and behaves exactly like invoking the executable.