nixpkgs/pkgs/top-level/release-python.nix

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

73 lines
2.1 KiB
Nix
Raw Permalink Normal View History

/*
test for example like this
$ hydra-eval-jobs pkgs/top-level/release-python.nix
*/
{
# The platforms for which we build Nixpkgs.
supportedSystems ? [
"aarch64-linux"
"x86_64-linux"
],
# Attributes passed to nixpkgs. Don't build packages marked as unfree.
nixpkgsArgs ? {
config = {
allowUnfree = false;
inHydra = true;
};
release: forbid use of `lib.fileset` in Nixpkgs Due to Nix bug <https://github.com/NixOS/nix/issues/11503>, `builtins.filterSource` and chroot stores interact in a confusing and broken way that breaks `lib.fileset`. This means that uses of the API inside Nixpkgs keep breaking the NixOS installer, blocking the channel. The resulting error messages are inscrutable (they look like “the installer test is trying to download `curl`…?” and eventually bottom out in a derivation that has the wrong `outPath` because of the chroot store causing an incorrect `lib.fileset` result). Whenever this happens, someone (well, in practice K900 or I) has to bisect the change that introduced it and remove the use of `lib.fileset`. This has happened at least three times in the past four months (I believe I might actually be missing one here, but these are the ones I remember and could easily dig up): * <https://github.com/NixOS/nixpkgs/pull/340046> * <https://github.com/NixOS/nixpkgs/pull/352491> * <https://github.com/NixOS/nixpkgs/pull/369459> The options I see here are: 1. Forbid use of `lib.fileset` within Nixpkgs until the Nix bug is fixed. This is the approach taken here. External users of Nixpkgs can continue to use the API as normal, but using it from within something that affects any release jobset `outPath`s will cause an evaluation failure with a hopefully‐helpful error message. 2. Forbid `lib.fileset` and also all of the other library APIs that use `builtins.filterSource`. I’m happy to do this, but so far none of those have broken the installer, so I decided to start small and worry about the others if they end up causing a problem in practice. 3. Forbid `builtins.filterSource` directly. This is hard and would require more invasive `builtins.scopedImport` crimes to do at evaluation time. I think this would realistically have to be done in something like nixpkgs-vet instead and I didn’t have much luck shoehorning a check like this into that codebase when I tried. 4. Fix the Nix bug. This would be great! But also it doesn’t seem to be happening any time soon, it seems difficult to fix in a way that doesn’t subtly break compatibility with the previous semantics, and arguably the fix would need backporting all the way back to 2.3 given our minimum version policy. 5. Do nothing; have people continue to innocuously use `lib.fileset` throughout Nixpkgs, breaking the installer whenever one of them sneaks in to that closure, causing the channel to be blocked and requiring expensive bisections to narrow down the inscrutable test failure to the package using `lib.fileset`, which then needs moving back off it. This sucks for the people who keep having to track it down, holds back important channel bumps, and the criteria for when it’s okay to use `lib.fileset` are not realistically possible to teach to all contributors. I'd be happy to work on (2) as an alternative; (3) would be difficult and seems like overkill, (4) is not really something I trust myself to do and wouldn’t address the immediate problem, and (5) isn’t sustainable. I think that the current approach here is the best trade‐off for now, as `lib.fileset` seems to be the only prominent user of the `builtins.filterSource` API that works with full store paths, exposing it to the Nix bug. It’s unfortunate to lose the nice API, but since we can’t rely on it to produce correct results and the channels keep getting blocked as a result, I don’t think we really have an alternative right now.
2024-12-30 15:36:05 +00:00
__allowFileset = false;
},
}:
let
release-lib = import ./release-lib.nix {
inherit supportedSystems nixpkgsArgs;
};
inherit (release-lib) mapTestOn pkgs;
inherit (release-lib.lib) isDerivation mapAttrs optionals;
packagePython = mapAttrs (
name: value:
let
res = builtins.tryEval (
if isDerivation value then
value.meta.isBuildPythonPackage or [ ]
else if
value.recurseForDerivations or false
|| value.recurseForRelease or false
|| value.__recurseIntoDerivationForReleaseJobs or false
then
packagePython value
else
[ ]
);
in
optionals res.success res.value
);
2022-02-11 11:35:21 -08:00
jobs = {
lib-tests = import ../../lib/tests/release.nix { inherit pkgs; };
pkgs-lib-tests = import ../pkgs-lib/tests { inherit pkgs; };
tested = pkgs.releaseTools.aggregate {
name = "python-tested";
meta.description = "Release-critical packages from the python package sets";
constituents = [
jobs.nixos-render-docs.x86_64-linux # Used in nixos manual
jobs.remarshal_0_17.x86_64-linux # Used in pkgs.formats.yaml_1_1
jobs.python312Packages.afdko.x86_64-linux # Used in noto-fonts-color-emoji
jobs.python312Packages.buildcatrust.x86_64-linux # Used in pkgs.cacert
jobs.python312Packages.colorama.x86_64-linux # Used in nixos test-driver
jobs.python312Packages.ptpython.x86_64-linux # Used in nixos test-driver
jobs.python312Packages.requests.x86_64-linux # Almost ubiquous package
jobs.python312Packages.sphinx.x86_64-linux # Document creation for many packages
2022-02-11 11:35:21 -08:00
];
};
} // (mapTestOn (packagePython pkgs));
in
jobs