| 8 Jul 2024 |
|  @julienmalka:matrix.org left the room. | 10:39:15 |
|  @felixalb:feal.no joined the room. | 16:16:05 |
 infinisil | notashelf: It's a bit tricky unfortunately, but: https://github.com/NixOS/nixpkgs-check-by-name/issues/56 | 17:21:25 |
| infinisil | notashelf: A bit easier is https://github.com/NixOS/nixpkgs/pull/322537, for which it would be best to join #nix-formatting:nixos.org :) | 17:22:16 |
|  @ktemkin:katesiria.org left the room. | 17:35:52 |
 emily | re "Which files are part of a package?", a reasonable start would be just migrating packages that only have default.nix in their directory and nothing else, right? | 17:37:15 |
| infinisil | emily: Good idea, that sounds decent! | 17:59:00 |
| emily | emily@yuyuko ~/D/nixpkgs ((8e484a4c))> ls pkgs/*/*/default.nix | wc -l
965
emily@yuyuko ~/D/nixpkgs ((8e484a4c))> for file in pkgs/*/*/default.nix; test (count (dirname $file)/*) = 1 && echo x; end | wc -l
660
| 18:10:40 |
| emily | that would work for ~68% of packages | 18:10:49 |
| emily | I imagine the rest are mostly divided into "things that vendor something like a Cargo.toml or a few patches" and "things that are going to have to be manually migrated anyway" | 18:11:25 |
| emily | btw, I assume the intention is to get rid of all the "alternative" callPackage/mkDerivation analogues at some point so that everything can be by-name? | 18:24:10 |
 Philip Taron (UTC-8) | callPackage works for a host of things (factories, generators, functions of various sorts) that pkgs/by-name rejects -- in particular, the nixpkgs-check-by-name tool rejects them. | 19:12:58 |
| emily | right; I guess I mean for actual derivations | 19:42:07 |
| emily | like Python or Qt stuff | 19:42:10 |
| emily | (I would certainly be happy to see those go, as they obviously don't compose) | 19:42:30 |
| Philip Taron (UTC-8) | In reply to @philiptaron:matrix.org
When I run maintainers/scripts/check-by-name.sh master locally in my nixpkgs repository, without any changes, I get this error:
I/O error: Failed to get the definition info for attribute acl: In /tmp/tmp.bQmCobXFGj/merged/pkgs/stdenv/linux/default.nix, attribute parent node is not an attribute path node: NODE_INHERIT@28432..28603
Does anyone else reproduce this? It appears to be about this line in pkgs/stdenv/linux/default.nix:
inherit (prevStage)
gzip bzip2 xz bash coreutils diffutils findutils gawk
gnused gnutar gnugrep gnupatch patchelf
attr acl zlib libunistring;
I've opened https://github.com/NixOS/nixpkgs-check-by-name/issues/78 for this issue. Doing some diagnostics now. | 20:20:36 |
| Philip Taron (UTC-8) | And https://github.com/NixOS/nixpkgs-check-by-name/pull/79 now too in order to fix it. CC willbush and infinisil . | 20:45:05 |
 Qyriad | In reply to@emilazy:matrix.org
(I would certainly be happy to see those go, as they obviously don't compose) have you seen the lib.extendMkDerivation PR? | 20:50:55 |
| emily | nope, thanks for the pointer; subscribed | 20:52:12 |
| emily | it seems like it still wouldn't work with the by-name model though | 20:52:22 |
| emily | I sort of imagine we want a world where it looks like stdenv.mkDerivation { mixins = [ qtMixin pythonMixin ]; … } or something | 20:52:50 |
| emily | I guess we could write something like qtMixin (pythonMixin stdenv.mkDerivation) { … }? | 20:53:04 |
| emily | well, it's really the callPackages that are the problem though, not mkDerivation | 20:53:17 |
| emily | which gets into splicing stuff that I've never fully understood | 20:53:32 |
 Colin | In reply to @emilazy:matrix.org
I sort of imagine we want a world where it looks like stdenv.mkDerivation { mixins = [ qtMixin pythonMixin ]; … } or something both buildRustPackage and buildPythonPackage can be replaced with stdenv.mkDerivation and adding the appropriate setup hooks to nativeBuildInputs (e.g. cargoSetupHook or pypaSetupHook). i think the qt5.callPackage stuff is in a similar state.
the Python folk seem very against the idea of replacing buildPythonPackage with mkDerivation. i think there's more appetite for that on the Rust front.
| 21:01:05 |
| Colin | In reply to @emilazy:matrix.org
I sort of imagine we want a world where it looks like stdenv.mkDerivation { mixins = [ qtMixin pythonMixin ]; … } or something * both buildRustPackage and buildPythonPackage can be replaced with stdenv.mkDerivation and adding the appropriate setup hooks to nativeBuildInputs (e.g. cargoSetupHook or pypaBuildHook). i think the qt5.callPackage stuff is in a similar state.
the Python folk seem very against the idea of replacing buildPythonPackage with mkDerivation. i think there's more appetite for that on the Rust front.
| 21:02:59 |
| Qyriad | buildPythonPackage very recently became a fair bit more than equivalent to mkDerivation with some setup hooks, now that it takes the pythonic dependencies and build-system arguments and mkDerivation-ifies them | 21:22:18 |
| 9 Jul 2024 |
| emily | right | 03:17:17 |
| emily | what about the callPackages? are those "just" the same as callPackage that brings another namespace into scope too? I've never been entirely clear on that | 03:17:40 |
 tomberek | emily: The callPackages serve the same purpose, but there are minor differences in how some of the package sets are put together due to historical accident. This is why each package set (eg: pythonPackages, rubyPackages, etc) has differing behavior and instructions for use. Standardizing these would be a huge win. | 03:53:19 |
