Sender | Message | Time |
---|---|---|
8 Jul 2024 | ||
emily: Good idea, that sounds decent! | 17:59:00 | |
| 18:10:40 | |
that would work for ~68% of packages | 18:10:49 | |
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 | |
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 | |
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 | |
right; I guess I mean for actual derivations | 19:42:07 | |
like Python or Qt stuff | 19:42:10 | |
(I would certainly be happy to see those go, as they obviously don't compose) | 19:42:30 | |
In reply to @philiptaron:matrix.orgI've opened https://github.com/NixOS/nixpkgs-check-by-name/issues/78 for this issue. Doing some diagnostics now. | 20:20:36 | |
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 | |
In reply to@emilazy:matrix.orghave you seen the lib.extendMkDerivation PR? | 20:50:55 | |
nope, thanks for the pointer; subscribed | 20:52:12 | |
it seems like it still wouldn't work with the by-name model though | 20:52:22 | |
I sort of imagine we want a world where it looks like stdenv.mkDerivation { mixins = [ qtMixin pythonMixin ]; … } or something | 20:52:50 | |
I guess we could write something like qtMixin (pythonMixin stdenv.mkDerivation) { … } ? | 20:53:04 | |
well, it's really the callPackage s that are the problem though, not mkDerivation | 20:53:17 | |
which gets into splicing stuff that I've never fully understood | 20:53:32 | |
In reply to @emilazy:matrix.org both the Python folk seem very against the idea of replacing | 21:01:05 | |
In reply to @emilazy:matrix.org* both the Python folk seem very against the idea of replacing | 21:02:59 | |
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 | ||
right | 03:17:17 | |
what about the callPackage s? 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 | |
emily: The callPackage s 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 | |
it's always been a little funny to me that Nixpkgs of all things bakes in an assumption that a piece of software uses at most one ecosystem :) | 03:54:18 | |
12 Jul 2024 | ||
I'll be in my weekly office hour again today in 10 minutes: https://meet.jit.si/nixpkgs-architecture :) | 17:51:22 | |
Ping @willbush:matrix.org @philiptaron:matrix.org @dmills27:matrix.org @raf:notashelf.dev @emilazy:matrix.org in case anybody wants to join :) | 17:52:48 | |
14 Jul 2024 | ||
In reply to @infinisil:matrix.orgI plan on attending this coming week, as I will be at home as opposed to travelling. | 23:48:26 | |
15 Jul 2024 | ||
infinisil: I'm blocked on adding the regression test you asked for in #79 by failing to understand how to ask Nix for the line/position numbers. | 15:00:22 | |
Philip Taron (UTC-8): I was about to hit enter haha: https://github.com/NixOS/nixpkgs-check-by-name/pull/79#issuecomment-2228713375 | 15:01:02 |