building Nix...
building the system configuration...
error: Package ‘python-2.7.18.6’ in /nix/store/x0r039vbmvnf65y035qsh66kpcchi3lf-nixos-23.05/nixos/pkgs/development/interpreters/python/cpython/2.7/default.nix:330 is marked as insecure, refusing to evaluate.
Known issues:
- Python 2.7 has reached its end of life after 2020-01-01. See https://www.python.org/doc/sunset-python-2/.
You can install it anyway by allowing this package, using the
following methods:
[...]
How can I easily know which package/configuration is depending on it? I tried to ask for the trace using –show-trace but I got a long list of calls, where maybe the only one that could make sense was
while evaluating the attribute ‘serviceDirectories’ of the derivation ‘dbus-1’
but I don’t require it directly, so I’m not sure how can I get rid of it.
I know you can also do something with nix-env --query if you’re not using the new CLI, but I don’t recall the one liner to do that off the top of my head.
I could use nix-env --query but the problem I have is that the derivation is not built, so it is not stored and I don’t even know the package/hash name that the python module would have.
I could use it in case I want to understand how my current system was created, but I’m not able to create a new system derivation at all so I can’t inspect the derivation dependency tree.
Not really a solution, but I added python2 as an insecure package, so I was able to build the new system and so after querying the dependency tree I figured out that ecryptfs-helper was the culprit, package that I don’t even need anymore
Hmm, in theory it should be possible to know what the path will be ahead of time, but I guess not if nix doesn’t evaluate the package. Feels like an edge case that should be covered.
Hi @richard, how did you query the dependency tree after building your system? I got the same problem and tried nix-store -q --referrers /nix/store/1zczmi8am3qv78v1lwjdvpw6arag0gja-nixos-23.05/ but this only yields user-environment and env-manifest. I already did nix-env -e \* for my user and root to clear the nix-env but this has no effect on the error.
I run into the same issue, but I cannot not figure how to use nix why-depends to check for the dependency of my entire nixos configuration on top of python-2.7
EDIT: apparently /run/current-system still points to the old nixos build, which depended on 22.11 channel, but my local nixpkgs already points to 23.05 when reverting to 22.11 I actually see a dependency
better than nothing, but of course the real goal is to get the dependency conflict on the new/current nixos config with channel 23.05.
EDIT2: To get the diff on the new configuration.nix alternative you apparently need to build it first (with allowing for insecure features) which will update run/current-system and then run the above again
Yeah, hence my comment about it needing to be evaluated, which AIUI aborts if the package is insecure/broken/non-FOSS. I’ve never used the flag @NobbZ suggested, you would need to point to the system derivation rather than the path of its output, which I’m not entirely sure how to get a reference to. There’s probably a way, I’d need to dig into the guts of nixos-rebuild again and figure out what to substitute…
If you’re not using it for the current system, you can also use nixos-rebuild build and point why-depends at the result symlink, so you don’t actually need to deploy anything. Could be a workaround to get more convenient access if the package is just insecure/non-FOSS, but wouldn’t work for an actually broken package.
There’s clearly a need for better tooling around this, but the good news is all the data seems to exist. Now just need a UI.