Closed tarsius closed 1 year ago
IMO the only packages that really need this are those that have a build-step that has to be run to produce something suitable for distribution on melpa. (And that should be avoided whenever possible too.)
Yes, this is precisely the reason. The dynamic modules need to be built first.
I have mulled over this dynamic-modules-and-melpa problem for a long time, but haven't had time to write down my thoughts yet. I'll do that when I have time for my digital life again, hopefully in December. I won't be able to discuss further before that.
I would like to remove that override from the melpa recipe.
Not sure about the rationale, but my general principle is build infra should avoid churns and breaking changes, even at the cost of ugly code.
I have mulled over this dynamic-modules-and-melpa problem for a long time, but haven't had time to write down my thoughts yet. I'll do that when I have time for my digital life again, hopefully in December. I won't be able to discuss further before that.
Looking forward to reading about that from someone who has more than a bit experience with it. I hope you will present a solution. :grin: I'm happy to wait for that until the end of the year -- too busy myself right now anyway.
Is really necessary to build the melpa ("unstable") packages from the "release" branch? I would like to remove that override from the melpa recipe.
There are currently only ten recipes that set
:branch
and I would to get that number down even more. (Three other packages will soon stop doing it.) IMO the only packages that really need this are those that have a build-step that has to be run to produce something suitable for distribution on melpa. (And that should be avoided whenever possible too.)Same for
tree-sitter-langs
. (Here "master" and "release" even point at the same commit; in the case oftree-sitter
"master" is a few commits ahead.)Thanks for considering.