i.e. merging #270537 with { callPackage, ... }: as the argument, and then later doing something like

{
  callPackage,
}:

i.e. merging #270537 with { callPackage, ... }: as the argument, and then later doing something like

{
  callPackage,
  packageFromDirectory ? path: callPackage path {},
}:

In reply to @philiptaron:matrix.org
infinisil: I love pkgs/by-name and I write Rust at work. I'd be glad to be code reviewer when you're ready.

In reply to @philiptaron:matrix.org
infinisil: I love pkgs/by-name and I write Rust at work. I'd be glad to be code reviewer when you're ready.

In reply to @9999years:matrix.org

i.e. merging #270537 with { callPackage, ... }: as the argument, and then later doing something like

{
  callPackage,
  packageFromDirectory ? path: callPackage path {},
}:

In reply to @infinisil:matrix.org
I just cleaned up the PR and marked it as ready to review, it would be great if you could take a look now! Best reviewed commit-by-commit, they all come with commit messages: https://github.com/NixOS/nixpkgs/pull/272395

In reply to @infinisil:matrix.org
So we could have e.g. a module.nix file that specifies a NixOS module (or home-manager module, or some abstract module, ..)

In reply to @philiptaron:matrix.org
Taking a look. I could pair review on a call. It's 19:45 PST and I'm available for another 45 minutes. :-)

In reply to @philiptaron:matrix.org
Taking a look. I could pair review on a call. It's 19:45 PST and I'm available for another 45 minutes. :-)

In reply to @infinisil:matrix.org
Oh yeah that was at 5am for me, maybe that won't work that well haha

I did end up taking a look through the PR. It all looks sane. I have various code organization suggestions, but the current organization isn't bad at all and I would definitely accept it.

Most of the code organization suggestions end up being "make a method on NixpkgsProblem named for the condition that will be created", and returning Option<Self>. That would make check_values look super sleek by sequencing together all the various checks, rather than bulky due to having the checks inlined.

One "rusty" nit is to have the various things accepting &Vec<Something> accept instead the slice &[Something]. That's both lower power and more general.

Thanks for doing this work! Big win across the board already, and more to come.

In reply to @infinisil:matrix.org
I just cleaned up the PR and marked it as ready to review, it would be great if you could take a look now! Best reviewed commit-by-commit, they all come with commit messages: https://github.com/NixOS/nixpkgs/pull/272395

Btw the RFC specifies to do it in a different way, but the basic idea is the same:

All satisfying definitions that can't be automatically migrated due to the above restrictions will be added to a CI exclusion list. CI is added to ensure that all satisfying definitions except the CI exclusion list must be using the new directory structure. This means that the new directory structure becomes mandatory for new satisfying definitions after this PR. The CI exclusion list should be removed eventually once the non-automatically-migratable satisfying definitions have been manually migrated. Only in very limited circumstances is it allowed to add new entries to the CI exclusion list.