Closed savetheclocktower closed 1 week ago
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.
Failing editor test is the one that's known to be flaky. Not going to bother with re-running it for now.
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.
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.
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.
I'm not sure if
pulsar.sh
was ever expected to work for.tar.gz
bundles, as it's just as easy to call thepulsar
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.
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:-p
/--package
need to get all the way to Pulsar before they’re handled. We should redirect them toppm
inpulsar.sh
.pulsar
go tostdout
instead ofstderr
.pulsar.sh
hard-codes an assumed install location — presumably the place it resides when installed viarpm
ordeb
. If a user has downloaded thetar.gz
version,pulsar.sh
will fail to find their installation automatically, even thoughpulsar.sh
lives within that directory.Description of the Change
stderr
.-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 callingppm
instead of Pulsar.pulsar.sh
is invoked from a symlink, it should now be able to determine its real location, then traverse upward to find a binary calledpulsar
.PULSAR_PATH
environment variable manually.pulsar -p --version
prints the version information for Pulsar instead ofppm
.Alternate Designs
We already do the main alternative to handling
--package
inpulsar.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
pulsar --package --version
pulsar -p -v
ppm --version
pulsar --wait --package --version
(testing that any arguments before--package
are ignoredpulsar --package list
pulsar -p list
ppm list
pulsar -v --package list
--package
/-p
behave like they always did:pulsar .
pulsar --dev .
pulsar --wait foo.js
pulsar --test spec/*-spec.js
Extra testing for Linux:
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 thatpulsar-test
passes all the manual tests described above.Release Notes
pulsar
script’s ability to find the user’s Pulsar installation location on Linux.pulsar -p
now invokesppm
without having to launch Pulsar itself.