Regression in init subcommand: IOH.Base does not implement write_file

[Peeperkorn]

Heyhey, noob here. I wonder why I get error 127:

My command, in /usr/local/lib/node_modules/@castlelemongrab/parlance (there is no config folder there btw):

parlance init --mst "$mst" --jst "$jst" -o config/auth.json

(node:11054) UnhandledPromiseRejectionWarning: Error: Process exited with status 127

at IOH.fatal (/usr/local/lib/node_modules/@castlelemongrab/parlance/node_modules/@castlelemongrab/ioh/src/ioh.js:57:11)
at Session.write_credentials (/usr/local/lib/node_modules/@castlelemongrab/parlance/src/session.js:84:18)

(Use node --trace-warnings ... to show where the warning was created)
(node:11054) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag --unhandled-rejections=strict (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 2)
(node:11054) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

[pranithapat]

Were you able to resolve this issue? I'm having the same problem.

[castle-lemongrab]

Sorry for the delay in responding. I am able to reproduce this, and will get it fixed as soon as possible. We're a little bit disrupted by the pandemic over here, so I'm moving more slowly than I'd like to.

In the mean time, you should be able to create a compatible auth.json file by simply creating a file of the form { "mst": "...", "jst": "..." }, where each ellipsis has been replaced with the a non-urlencoded version of the token. If the token you have is URL-encoded (i.e. contains something like %2A), you should be able to use something like decodeURIComponent(mst) to get the plain-text representation.

This is pretty obviously a regression, so I'll attempt to prioritize it.

[castle-lemongrab]

This one was a complete facepalm; it should be fixed in 986542a. Let me know if any difficulty continues. I'll leave this open and merge in a unit testing framework and a couple of tests to guard against this sort of regression in the future. I'll also file an issue for end-to-end "it still works" testing.

I had some questions about how fast Parler's engineering team was able to move, and delayed introduction of proper TDD in anticipation of them rapidly changing interfaces/APIs. As it turns out, they are not moving very fast.

[castle-lemongrab]

Given that this issue lies in a critical path for people getting started, I'll go ahead and just add one unit test and push a new release; splitting off the other concerns. That way it'll work out of the box ASAP. Thanks for your patience.

[sipka]

I have been tracking this as I am also hitting the issue and am therefore unable to use the API. Any suggested workaround until the issue gets reviewed and gets into the package? Thanks for your work, btw, this is would be a super helpful package for my research!

[castle-lemongrab]

I've released version 1.127.0 to Github and NPM to address this. If you're still seeing this issue or a similar issue after updating, let me know.

Given that Parler may be hanging around for a while, we intend to prioritize unit testing and end-to-end testing in the near term, as well as increase the frequency of NPM releases.

[sipka]

All good now, thanks! I needed to do mkdir config manually first and then it was happy enough. Thank you!