Open roberth opened 1 year ago
After discussion with @Ericson2314 we'll also want to use a script to fill a complete set of non-unique packages anyway, so the solution has two parts
I'll also note that we may want to switch to a json as the primary data source, which would allow the consumer to do more. Platform-specific exceptions can be overlaid on top of that in Nix, or be represented in the json. Examples: hidapi
, wayland
. Both are packages that have a different set of pkg-config modules depending on the platform.
as the data does not to be polished up
For now not but over time we surely need to move/remove entries because the actual files might change.
nix-index ...
nix-locate -r 'lib/pkgconfig/.*.pc$'
We should searczh for any .pc$ file to find misplaced ones.
I'll also note that we may want to switch to a json as the primary data source
If we would use yaml, we could work with anchors for duplicated data.
For now not but over time we surely need to move/remove entries because the actual files might change.
That's where the tests come in. Also @Ericson2314 suggests using the package meta for this. This allows for a more sustainable architecture where
meta
attribute.meta
attribute is tested in CI. OfBorg should cover this fairly well, and hydra could summarize it.meta
attribute information. This serves as an index for lang2nix tools, as they need a function module -> package
; not package -> module
.nix-index
is only used for finding new packages that haven't received meta
info yet. At least for the initial effortofborg
could force-apply the meta
tester from https://github.com/NixOS/nixpkgs/pull/214304 to the changed/added packages that it builds, which is a check that really any package can and must satisfy anyway. When we have this, nix-index
isn't needed anymore.If we would use yaml, we could work with anchors for duplicated data.
For now a JSON is better, because it can be read by Nix without it having to build anything. If yaml support is added to Nix at some point, this may be a consideration, but as a performance optimization. I doubt that we need it, as git is quite clever with deduplication and general compression. It might only save some space when unpacked, which doesn't seem like much of a problem.
https://github.com/NixOS/nixpkgs/pull/215198 this would prepare for that.
Project description
After #212282, we'll have a set of aliases for pkg-config packages to be used by lang2nix integrations. The list is manually curated, but we have the tools to fill the list with (almost) all pkg-config-supporting packages that we have. I'm not suggesting to regenerate the list from scratch; as the data does not to be polished up, not to select the wrong
_version
variant, becausenix index
isn't always complete, and possibly other reasons. Instead, my suggestion is to add a script that any maintainer can run, to see if we have any pkg-config packages in anix-index
index, that haven't been added to the #212282 package set yet.Starting point
This returns an output of the shape:
The file name at the right hand side, before
.pc
, is should correspond to an attribute name in thepkg-configPackages
package set. When it is missing, the script can make a suggestion, such as addingand so on.
This list of suggestions will contain duplicates, in which case they should be reported separately, as these cases seem to require a human to decide which attribute is the best default. (Though perhaps the shortest name may turn out to be a good heuristic)
Regarding the repology label, from what I've heard there's interest from repology to reuse our pkgconfig metadata.
Metadata