When I updated my system I always got
building the system configuration...
error: yutto should use `buildPythonPackage` or `toPythonModule` if it is to be part of the Python packages set.
(use '--show-trace' to show detailed location information)
What should I do to fix it? Thanks!
“yutto” is not packaged upstream, so this must be something you added yourself. It probably just needs migrating to a new nixpkgs concept. Can you show where you create that package?
Well, yes, I should migrate it.
Huh, it refuses to show up in the package search. Where do you install it in your config, out of interest?
Just install it directly into systemPackages.
I gues this is because it’s not in 22.05 and in unstable the build failed.
Aaah, I see now. Yeah, this is a regression, caused by pythonPackages: ensure all derivations provide python modules by FRidh · Pull Request #194205 · NixOS/nixpkgs · GitHub (or more likely, the follow-up from 4 days ago that added exceptions but changed the logic a bit). Probably should move this to #dev if you intend to fix the package yourself, otherwise file an issue and wait for someone to fix it.
@FRidh looks like this is not the only case, see platformio: fails to build on nixos-unstable · Issue #198319 · NixOS/nixpkgs · GitHub. Do you have any quick advice on migrating packages that fall over because of this? Sounds like they should be moved out of the
pythonPackages set and into the top-level, but I don’t really follow the intention behind the change
I suppose your commit message is pretty clear:
Python packages can be grouped into two groups: 1) applications and 2)
packages providing importable modules. In
python-packages.nix we only
want to have 2). 1) should be in the top-level package set.
But the commit also reads as if these regressions weren’t intentional, since it’s only supposed to apply to new packages. Should accidental breakage like this be migrated to top-level or is there some bigger underlying oversight?
I’m also curious why e.g.
youtube-dl isn’t affected by this. Is it the python version condition?
Yes, that one. @K900 said that it’s a poetry2nix issue but it seems it’s not… And it seems the author doesn’t care about these packages when they made the change. I’ll fix the packages I maintain and use.
Doubt it’s a case of “don’t care”, @FRidh made some changes to fix broken packages just a few days ago. I think this just needs a bit of coordination, so good thing you started this thread.
poetry2nix issues have been flying around too, so I can see why you’d assume that, but the errors caused by those packages were different. I could be wrong, though.
I have fixes two pkgs I maintain/use. And I searched
../applications and found another two affected pkgs:
xxh is another one.
There are a dozen or so packages incorrectly in
python-packages.nix. These expressions/locations need to be fixed and this is up to the maintainers of those packages. I’m not going to decide where they should go, just that they don’t belong in
python-packages.nix as they are.
The motivation for this change is to enforce the policy that has been around for some years that only
toPythonModule should be in that file. Having non Python module packages in the package set can cause other weird issues when people try to use them hence that policy.
This package correctly uses
buildPythonPackage, however, it is not in
pkgs/development/python-modules. The new change does not actually check the location.