treewide: add meta.mainProgram to (almost) all packages with a single binary#297084
treewide: add meta.mainProgram to (almost) all packages with a single binary#297084mweinelt merged 1 commit intoNixOS:masterfrom
Conversation
The nixpkgs-unstable channel's programs.sqlite was used to identify packages producing exactly one binary, and these automatically added to their package definitions wherever possible.
stuebinm
requested review from
FRidh,
Ma27,
Mic92,
RaghavSood,
RaitoBezarius,
aanderse,
adisbladis,
ajs124,
dasJ,
drupol,
figsoda,
globin,
jonringer,
jtojnar,
lilyinstarlight,
lukegb,
mkg20001,
mmahut,
mweinelt,
roberth,
stigtsp,
talyz,
teto,
ulrikstrid,
winterqt,
zakame and
zowoq
as code owners
github-actions
bot
added
6.topic: python
github-actions
bot
added
6.topic: xfce
ofborg
bot
added
10.rebuild-darwin: 1-10
|
I skimmed the changeset, and it looks plausible. Given that it doesn't break eval or check-meta, let's give it a shot before it rots away. Thanks for your work on this! |
|
There are some packages like the Python library Amaranth which have found a random utility script as the I don't object to this PR but I think it's worth being aware of. |
|
@tpwrules yes, that occurred to me as well — in the end, I didn't do anything about it, because I don't think that this is, as such, wrong? It might still enable nice things to have it there (be it for (wondering out loud for a bit: perhaps it would be useful to have a |
Lock package versions using absolute paths to increase package purity by
wrapping scripts in 'pkgs.writeShellApplication' with runtime
dependencies, or by passing the following values in ascending order of
availability to "lib.getExe" or "lib.getExe'":
1. config.<MODULE>.finalPackage
2. config.<MODULE>.package
3. pkgs.<PACKAGE>
The 'lib.getExe' function causes the following errors for the
'rofi-pass-unstable-2024-02-13' and 'xplr-0.21.5' packages:
trace: warning: getExe: Package "<PACKAGE>" does not have the
meta.mainProgram attribute. We'll assume that the main program has
the same name for now, but this behavior is deprecated, because it
leads to surprising errors when the assumption does not hold. If the
package has a main program, please set `meta.mainProgram` in its
definition to make this warning go away. Otherwise, if the package
does not have a main program, or if you don't control its
definition, use getExe' to specify the name to the program, such as
lib.getExe' foo "bar".
In the future, updating the '/flake.lock' file to
NixOS/nixpkgs#297084 should resolve this issue.
|
hm, this link seems dead? |
github-actions
bot
added
the
6.topic: julia
ah, i renamed the repository once it turned into a slightly more general tool; I've now updated the link to again point at the version which was used for this PR (if you want to use it, be aware it's very much single-purpose & brittle)
neither of these are "trivial" for the purposes of this PR; they both provide more than one binary (an easy way to check this is to use search.nixos.org, which uses the same I had deliberately excluded such packages which provide a binary named identically to their |
4 participants
Description of changes
Set
meta.mainProgramautomatically for "trivial" cases of packages which produce only one binary (as determined by the nixpkgs-unstable channel'sprogram.sqlitedatabase).Motivation:
#246386 has deprecated the assumption that a package's main program (if not set explicitly otherwise) has the same name as the package itself. Thus using
lib.getExeon a vast number of existing packages has become essentially unsupported.Unfortunately, it seems infeasable to set
mainProgramfor all existing packages manually. A rough estimate of the problem's scale was given in #219567 (comment), which estimates last year that there were around ~5500 packages affected.I've previously opened individual PRs adding
mainProgramto single packages when I came across one where it was missing, but honestly I don't look forward to dealing with this until ~2030 at least (rate estimated by running the above-linked script again now), so I thought it was worth looking at another approach.Implementation
Builing on @emilylange's script (linked above), it's pretty easy to get a list of candidate packages which produce exactly one binary (which must hence be that package's
mainProgram), but which do not actually set this in theirmetablock. I consider these "trivial" cases to be fixed. Currently (before this PR), there are 6921 of these.Using
meta.position, it is further (mostly) easy to get each candidate's definition site (exception: things produced e.g. via the builders inbuild-support/trivial-builders, wheremeta.positionpoints to the builder's definition instead).Candidates can then have a
meta.mainProgramentry added to their source automatically, for which I wrote a little rust tool to edit package definitions (loosely based on nix-doc-munge which was written for the doc migration from AsciiDoc).Consideration & special cases:
The automatic rewriting does two things:
metablock, it will add amainProgram = ...in the next line after thedescriptionentrymeta.mainProgram = ..attribute to the end of the attribute setmetablock and instead keepdescription,mainProgram, etc., as direct attributes of the package description. I have found no better way to reliably identify these than to see if the derivation has a top-leveldescription(or similar) attribute; in this case, nometablock will be created.Results
Of 5457 files defining the candidate packages, 5373 were edited; in 84 cases my script did nothing:
meta.positionof different packages, which I simply chose to ignoremetaattributemetaattrset but failed to edit it (theselack
descriptionattributes, and it only knows how to insert something after that)Re-searching for candidates with the changes applied reduced their number to 381. Still not nothing, but a lot more manageable.
Unexpected results
I thought this would be a no-op as far as packages are concerned, but turns out it is not:
Result of
nixpkgs-reviewrun on x86_64-linux 14 packages built:
This is a single package which has
src = ./.set, so since its own package definition is part of the source, it does get changed.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.