Prepare for MELPA PR (work in progress)

[jscheid]

No description provided.

[aspiers]

Ah, I just found this - looks great! What is left to be done?

[jscheid]

@aspiers mainly deciding if this is really the way to go, and then some testing and updating the docs.

I despise the idea of checking binaries into VC, here I'm exploring it as the potentially least bad option, relative to the amount of work that would need to be done for other solutions such as switching to using diff(1).

I'd be keen to hear your thoughts, you appear to be in favor?

[aspiers]

I also generally despise checking binaries into VC ;-) But maybe it's not a terrible compromise in this case - I'm not sure, because I don't entirely understand yet how the blob is used. How about wrapping make prettier-el.js.gz.base64 into an elisp defun which is called just-in-time before it is needed?

[jscheid]

What exactly are you suggesting, to check in the "linked" prettier-el.js, but uncompressed so that it's less of a blob? Or to link it on demand?

In the former case, I don't know if it would be an improvement; with optimizations enabled it's still mostly inscrutable, and disabling optimizations just for the sake of making it less opaque would be somewhat sad. Ultimately, we'd still be checking in build output.

In the latter, it currently needs a fairly specific build environment, and Emacs packages don't usually need to run a build step after installation. I'd foresee much frustration and need for hand-holding here on Github issues.

[aspiers]

@jscheid commented on June 10, 2020 12:49 PM:

What exactly are you suggesting, to check in the "linked" prettier-el.js,

I'm not sure what you mean by "linked"? And this file is already in git, so maybe I'm misunderstanding something.

but uncompressed so that it's less of a blob? Or to link it on demand?

No, I'm suggesting writing some elisp which generates the base64 file from the source just-in-time, and that it could reuse the existing Makefile rule.

In the former case, I don't know if it would be an improvement; with optimizations enabled it's still mostly inscrutable, and disabling optimizations just for the sake of making it less opaque would be somewhat sad. Ultimately, we'd still be checking in build output.

Right. I'm not proposing that.

In the latter, it currently needs a fairly specific build environment, and Emacs packages don't usually need to run a build step after installation. I'd foresee much frustration and need for hand-holding here on Github issues.

Right, that's why I've been inclined to propose dealing with this in a CI pipeline. Can GitHub publish build artefacts from non-release builds?

[jscheid]

I'm not sure what you mean by "linked"? And this file is already in git, so maybe I'm misunderstanding something.

By "linked" I mean the step that bundles prettier-el.js with diff-match-patch, which isn't really linking, hence the quotes. And yes, sorry, I meant prettier-min.el.js.

Right, that's why I've been inclined to propose dealing with this in a CI pipeline. Can GitHub publish build artefacts from non-release builds?

Good question, I guess it depends on what you mean by publish. For Melpa to pick things up, the artifacts would have to be pushed into VC again, right? That should be possible but we'd be getting into Rube Goldberg territory :-)

[aspiers]

For Melpa to pick things up, the artifacts would have to be pushed into VC again, right?

Ahhh, I thought there was a vanilla http :fetcher which could have been used to download artifacts from anywhere, but apparently not :-( I guess that changes things.

[jscheid]

Superseded by #25