ppm: Update ppm to commit a6f843f0381f64cb5865efc7

[DeeDeeG]

Includes the ppm Pull Request:

• Update to read v3 (ppm PR 150)
  • Update to read v3 ppm#150

---

Once again, a refresher on how to easily update a submodule:

In the root of pulsar repo:

• git submodule update --remote ppm
• git add ppm
• git commit

One can alternatively cd into the ppm dir, do things like git remote update and git checkout [commit from ppm repo], then cd back out to pulsar main dir and then git add ppm and git commit and it will record the arbitrary commit you checked out as the new submodule state. You could even author new commits that live only in the ppm submodule of pulsar repo, and not at the remote ppm repo itself! Yes, submodules can track original patches your upstream does not carry!!! Very flexible. A bit weird and arguably over-engineered. But it will let you do a lot, quite flexibly, if you know the rules or guess correctly with enough luck! (Just like the rest of git???)

[savetheclocktower]

I can verify that this picks the correct commit to update the ppm submodule with.

On the assumption that all the tests passed at the time that this was reviewed, and that manual testing was done, I have no problem approving this without having personally done the work of testing the integration into Pulsar.

The changes are limited to our usage of a single library and I can't really think of a way that this could go sideways.

[DeeDeeG]

Yeah, ppm CI passed and I manually tested that it worked over at ppm repo.

I feel that manually testing that it still works after landing over here would be a bit above and beyond for this sort of bump.

CI is passing here as well, I believe there are some package management things in editor tests that might fall apart if, say, ppm were totally broken?? So those passing is nice. (Other than settings-view, which CI appears to have spawned three redundant jobs for, one of which has passed, the other two of which are perpetually queuing??? I'm just gonna ignore the two extra/bugged ones...).

UPDATE: I did not end up ignoring it, curiosity got the better of me. Doing a re-run all, since re-running one of the perma-queuing ones seems to make it come back more numerous, like some sort of hydra... Will check on it tomorrow.

UPDATE 2: I filed a ticket with GitHub about the "duplicate matrix jobs" issue. Maybe they can fix that. But for now, one "real" copy of each job (all the non-duplicate or first copies) are all reporting passing and appear to have actually run, so I think we're good. Just have to remember that the real job count of the package tests workflow is 95, so if 95 are passing and the rest are duplicates queuing forever, we can pretty well ignore them.