melpa2nix: update to work with Emacs HEAD #276943
Conversation
We now use a newer version of package-build, since previously-necessary functions have been moved/removed from package.el Emacs 30. See melpa/package-build#87 Consequently, some changes are necessary to the corresponding patch and to melpa2nix.el, which this commit also contains.
purcell
force-pushed
the
melpa2nix-emacs-30
branch
from
92c315c to
4f12789
Compare
|
Running nixpkgs-review... |
|
Seems to rebuild all the emacs packages okay on my Here's an example of the problem this fixes in the wild btw: https://github.com/purcell/nix-emacs-ci/actions/runs/7328520844/job/19956927982 |
|
Successfully created backport PR for |
|
22k rebuilds across four platforms onto master is not really okay. Even if the builds are small, they clog hydra for a long time, disrupting its capability to deliver timely build results to end users. The rebuild flags really do reflect a traffic signal, and red means you have to stop. |
|
Apologies, I've only opened PRs against |
|
Successfully created backport PR for |
|
Git push to origin failed for release-23.11 with exitcode 1 |
Don't feel so bad. This was a recent unwritten decision. |
CONTRIBUTING.md linked in every single PR says: https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md#changes-causing-mass-rebuilds
There is nothing recent about this, it's been the policy for years. While I also don't blame @purcell for this (they didn't press the merge button, and trying to catch these issues is why we do reviews), it's surprising to me that an ex-committer to nixpkgs would claim this is a "recent unwritten decision". |
|
Thanks for sharing the docs. I did find that info after the fact. I wonder if there's some stricter automation that could prevent this sort of issue, e.g.
Effort spent on that automation might yield diminishing returns if the problems they mitigate are infrequent, I guess. |
|
"recent": for some period of time, emacs rebuilds were being merged directly into master with the argument that each of the many builds is very cheap. |
|
I could have sworn I checked that this was targeted against staging before merging. That was a mistake. |
|
Moved to |
Usually, mass rebuilds were not about the raw counting of packages being rebuilt, but about the depth of dependency tree/graph. Yes, the most glaring effect is the red circles Github bots provide, but usually they appeared for some special packages that were situated deeper in the Nixpkgs build graph. Softwares like Meson, Cmake or even GCC are indirect dependencies of a huge amount of different and otherwise unrelated packages. It is understandable that their mass rebuilds should be treated more carefully, since they bring profound modifications on the system as a whole. The same can't be said of Emacs. Emacs is mostly a dependency of Emacs Lisp packages, and Emacs Lisp packages are small and not useful outside Emacs itself. After Emacs being built, the Elisp packages can ideally be built in parallel. Further, we have such a huge amount of Elisp packages because their inclusion into Nixpkgs is automated. Very few of them are handwritten. Indeed we indulge ouserlves in relying on Emacs Overlay Project to provide up-to-date versions of those Emacs Lisp packages. Also, Emacs is not a "plumbing" package. Usually no one except developers care about if their Cmake or Meson packages are up-to-date. The same can't be said about Emacs since it is a package the users interact daily. Because of all of those things, it was considered OK to merge Emacs changes over master.
The unwritten policy of merging Emacs changes over master is almost as old as, well, adisbladis contributions I suppose? For a long amount of time, before the decision of providing precompiled Elisp packages, Emacs updates were sent to master branch. This trend continued for a very long time after that decision - indeed, I myself refactored the whole expression that builds two mainline, one experimental and two Macport releases, and absolutely no one thrown the Contributing Guide complaining about mass rebuilds.
Maybe because you wasn't there? #190706 - first time I catched Elisp updates triggering red flags And not a single mention of "what is a mass rebuild?" from Contributing Guide. Surprising! P.S.: since you bring my commit bit status, I lost it because I recklessly merged a mass-rebuild modification into master. Do you think each of the modifications I did above deserves the same exact chastisement? |
|
The commit where this was re-applied in |
|
It should get into channels over the weekend. |
Description of changes
When building recent Emacs HEAD with Nix,
melpaPackagesdo not build, since thepackage-build.elversion used here relies on a function inpackage.elthat has been removed.To resolve this, this PR makes
melpa2nixuse a newer version ofpackage-buildthat has been fixed to work with Emacs HEAD. See melpa/package-build#87Some changes have also been necessary to the corresponding patch and to the elisp in
melpa2nix.el.Edited for clarity
Things done
nix.conf? (See Nix manual)sandbox = relaxedsandbox = truenix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)Add a 👍 reaction to pull requests you find important.