Cleanup all-packages.nix #40047
Cleanup all-packages.nix #40047
Conversation
|
A couple questions:
1) Did you check that all removed Emacs packages are bit-by-bit equal (where it matters) to the ones in `emacsPackagesNg` or did you test the ones from `emacsPackagesNg`?
I'm asking because non-Ng `emacsPackages` still exist exactly because many packages from MELPA need some fixes/substitutions to work properly and non-Ng versions do those things, while `Ng` don't.
2) What are your thoughts on autogenerating `all-packages.nix`?
|
|
This is hard to review because it removes ~100 files, which as far as I can tell is not really related to all-packages.nix cleanup. |
|
Yes there might be some stuff in there worth keeping. It’s horribly out of date right now though. The ones I can find unavailable in *ELPA are ProofGeneral & Drew Adams’ packages. Are there any others? On autogenerated packages, I think we should wait until it becomes clear all-packages.nix is unmaintainable. Right now there are still lots of simple org stuff we can do. For instance I’d like to move all of the Linux kernels & Linux specific packages to their own attribute set. That alone could save us hundreds of lines. Other ideas like banning anything that’s not a derivation or attribute set from the all-packages.nix (there are a weirdly large number of functions that definitely should go somewhere else.) could help. My main concern with autogenerating is that it’s not always clear initially what is a simple packages vs. a complicated package. Most packages start off straightforward but then something like gtk3 comes along and we set gtk=gtk3 as a package argument. all-packages.nix is the place where we sort out all of the dependency conflicts between packages & autogenerated data would not have an easy way to do that. |
we don’t need to use recurseIntoAttrs twice
specifically what should go in unix-tools.nix
meta handles this for us
This adds some sections to the top of all-packages.nix. Here is the full list: - Standard environment tools - common tools provided by stdenv - Toolchains - compilers provided by different stdenvs - GCC - LLVM - Standard C libraries - libc used by different stdenvs - Glibc - Musl - Operating systems - OS specific packages (each now has their own file) - Compatibility layers - ‘meta’ packages that depend on the host platform Some things have been reworked to fit into the above framework, but hopefully this is not a mass rebuild.
|
Ok split off the Emacs stuff into #40132. |
|
Matthew Justin Bauer <notifications@github.com> writes:
Are there any others?
The problem is not unavailability, but non-triviality. Almost anything that has an untrivial builder in `emacsPackages` needs fixing and testing in `emacsPackagesNg`. I would just move `emacsPackages` into a separate file like `emacs-packages-old.nix` or something.
On autogenerated packages, ...
IMO `all-packages.nix` is pretty unmaintainable already. I'm 👍 on moving functions, fundamental things like libcs and cross gccs somewhere else. As to resolving conflicts in `all-packages.nix` I think we should just rescind the policy of "no versioned arguments". I see no benefit in `{ gtk, ...}: ...` that has to be immediately overriden with `gtk = gtk3` in `all-packages.nix`. Or, worse, but very common, `{ supportWhatever ? false }` immediately overriden with `supportWhatever = true` in `all-packages.nix`. The former just wastes space, the latter is also super-confusing.
|
I think in practice we do use versioned arguments a lot in Nixpkgs. I still think the original policy is good, just hard to enforce. The point is that we don't want new packages to use old dependencies & when they do it should be extremely obvious. For instance, if someone added a package that needs
Those are definitely bad & confusing. Ideally we would just have one or the other- either provide the default argument in |
|
I think in practice we do use versioned arguments a lot in Nixpkgs.
We do. But once in while people with commit access remember about this policy and make other people change perfectly good PRs.
I still think the original policy is good
I disagree. I think package-related things should be stored in the package expressions themselves, not dispersed through the rest of nixpkgs. I think that the original policy is good only for packages that are actually generic over the dependency version. That is, I prefer to think of package arguments as having "types". Do `gtk2`, and `gtk3` have the same "type"? For some packages, maybe, but most packages will distinguish between them at build-time, hence they should be different arguments of different "types".
The point is that we don't want new packages to use old dependencies & when they do it should be extremely obvious. ...
OfBorg checks evaluate all packages, hence the issue you describe is impossible.
I prefer the former but also realize it would make all-packages.nix even bigger without any obvious benefit (besides maybe discoverability).
See above.
|
|
Closing in favor of small PRs. |
Motivation for this change
This is another go at cleaning up all-packages.nix. This adds a few more sections to the top for `special' attributes to help us with organization.
Here is the full list:
Note that there are a bunch of changes waiting in staging. I will wait on those merging back into master before merging this because of the many conflicts it will cause.