Can't publish package

[Psychosynthesis]

Hi all!

I have updated one of my packages for use in Pulsar. Here is the address: https://github.com/Psychosynthesis/PulsarSync

I am doing the following:
pulsar -p login
Login successful. Next i try:
pulsar -p publish major

And then get error: Registering pulsar-sync Internal Server Error

I also tried
sudo pulsar -p publish minor
And... still get error.

What's wrong?

Pulsar  : 1.116.0
Electron: 12.2.3
Chrome  : 89.0.4389.128
Node    : 14.16.0
OS: Ubuntu 23.10

[confused-Techie]

Thanks a ton for reporting this issue! Taking a look at the backend, I can confirm that the backend is rejecting the publication of your package because the tag in your package.json isn't present on the repository, which PPM should be creating, but obviously is unable to because of the fact it's failing to save your credentials to the keychain.

So once we solve the keychain issue, we should be able to get everything fully functioning here.

Although I'm not too sure what immediately is wrong with the keychain here, so I'll look into it but ping @DeeDeeG as they are a bit more familiar with PPM's internals, but I'm not sure if that extends to it's module keytar which seems to be what's actually failing here.

[Psychosynthesis]

@confused-Techie ok. Will you update this issue when you finish?

[DeeDeeG]

Hmmm, yeah if keytar isn't doing what it's supposed to, that's not great.

I would not recommend running sudo. That should not be necessary.

[DeeDeeG]

I can try and walk through the steps of publishing a new package and seeing how it goes, as we have multiple reports of this issue lately, so if I walk through it myself, maybe that will clarify things...

[idleberg]

I have not been able to publish or update any package for the past year or so. The login works fine, but publishing always fails!

Not to depreciate anybody's effort, but given the general state of this project, I simply thought this is expected behaviour and never worked in the first place. Since the packages are at the core of the Atom/Pulsar experience, this should be fixed as soon as possible IMHO.

$ pulsar --version
Pulsar  : 1.121.0
Electron: 12.2.3
Chrome  : 89.0.4389.128
Node    : 14.16.0

$ ppm --version
ppm  2.7.0
npm  6.14.19-pulsar1-1
node 16.0.0 arm64
pulsar 1.121.0
python 

[idleberg]

If you signed up for Pulsar via OAuth, go to web.pulsar-edit.dev sign out, then sign back in

I followed this and I could publish a package. I tried repeating this for some of the packages I updated and created git tags for, but this time I'm running into an "Internal Server Error"

I also tried releasing this using a new version (ppm publish patch) – same error!

[confused-Techie]

Thanks for getting back to me @idleberg.
Taking a look at the request, I was able to see the actual error that should've been returned back to you (there's a PR to fix this already, so hopefully it'll be in production soon).

But the error that should be returned is Failed to find a matching tag: idleberg/atom-language-nsis - 8.20.0
What this means is that you've attempted to publish version 8.20.0 but that tag wasn't found on the GitHub repository for the package. But using ppm publish patch should create the tag prior to telling the backend to publish it, so it's rather interesting that this process seems to have failed.

But looking at your repository the package.json shows 8.20.0 as it's version, meanwhile no tag exists for that version.

While I'd love to look into why ppm publish patch is failing, if you just want to move past this and have the package updated creating a tag on GitHub for 8.20.0 then running ppm publish --tag 8.20.0 should work just fine. We just have to make sure that the version in the package.json is a tag available on GitHub to be able to publish.

[savetheclocktower]

It's because we assume that, when --tag is specified, that tag already exists:

https://github.com/pulsar-edit/ppm/blob/97f4d201be013157756a76008bf0cb55e6a1fe35/src/publish.js#L476-L477

The comment makes it clear that this is the intended behavior, but it should certainly be documented better. The usage text only vaguely hints at this behavior. There's also a stated requirement that the tag start with v, but I don't know if this is currently enforced.

@idleberg, in the example from your screenshot, you might try running ppm publish 0.13.2 instead; I think that'll automatically create the tag (with a leading v) before publishing.

[savetheclocktower]

I also tried releasing this using a new version (ppm publish patch) – same error!

@confused-Techie, if the “this” in that sentence refers to the example in the screenshot, you might want to check the logs for errors related to atom-local-storage rather than atom-language-nsis.

[confused-Techie]

@savetheclocktower Great callout on the package I was looking at. Was still using my previous search queries from the initial question, and didn't realize we switched packages, thanks!

So @idleberg the error we are seeing in atom-local-storage is indeed different. The error that should've been returned to you, which again is something we fix in pulsar-edit/ppm#139, should've been Failed to get GitHub Package idleberg/atom-local-storage - Server Error - 404. But unfortunately in this case it doesn't tell us quite what's wrong.

To sum up without going into too much depth, the backend failed to find a package.json associated with the tag 0.13.2. (Keep in mind you will want the tag you use in the CLI to match exactly with the tag on the web, such as v0.13.2) but that's not the issue here.

How did you create the tag 0.13.2 on idleberg/atom-local-storage? Since looking at idleberg/atom-local-storage#v0.13.2 GitHub shows a big error message that This commit does not belong to any branch on this repository, and may belong to a fork outside the repository. I'm not the most fluent in Git, so I can't say what really went wrong with your tag here. But I can say this error message doesn't appear for v0.13.1. So something definitely went wrong when creating that tag. Which we can confirm when attempting to manually make the same API call the backend does for the package.json we can see GitHub tells us it doesn't exist for that tag. Which when the backend gets this response is when it fails.

So you may want to take a look into how you created that tag originally, or delete it and try again, or even just bump another version using ppm to see if that creates the next tag appropriately. Also again keep in mind you'll want the version used in the CLI to match what's on GitHub like v0.13.2.