The dev’s explanation, in full, is:
The precompiled implementation is the only supported way to use the macros that are published in serde_derive.
If there is implementation work needed in some build tools to accommodate it, someone should feel free to do that work (as I have done for Buck and Bazel, which are tools I use and contribute significantly to) or publish your own fork of the source code under a different name.
Separately, regarding the commentary above about security, the best path forward would be for one of the people who cares about this to invest in a Cargo or crates.io RFC around first-class precompiled macros so that there is an approach that would suit your preferences; serde_derive would adopt that when available.
Not “Here’s why I’m doing this, it might seem weird but there’s a good reason” or anything. Just, go fuck yourself, run my binary.
I smell a similar resolution to the xfree86 -> xorg transition, where the community unanimously abandons serde in favor of the fork.
Related: https://programming.dev/post/1851005
Related how?
Linked post title: What is going on with serde?
If you read the linked post there you’ll see that it’s about devs discussing Serde’s actions on the GH issue. How are they not related?
They’re related. I was merely adding context here, because the comment only said it is related, but not how. (Hence why I put the supposed question in italics.) The context I would have liked to immediately know if I want to follow the link or not.
Ah, I see now what you meant. I thought you were being sarcastic due to the italics, my bad!
