8 Jul 2024 |
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 callPackage s 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 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 |
tomberek | 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 |
emily | 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 |
infinisil | I'll be in my weekly office hour again today in 10 minutes: https://meet.jit.si/nixpkgs-architecture :) | 17:51:22 |
infinisil | 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 |
Philip Taron (UTC-8) | In reply to @infinisil:matrix.org I'll be in my weekly office hour again today in 10 minutes: https://meet.jit.si/nixpkgs-architecture :) I plan on attending this coming week, as I will be at home as opposed to travelling. | 23:48:26 |
15 Jul 2024 |
Philip Taron (UTC-8) | 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 |
infinisil | 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 |
Philip Taron (UTC-8) | Sweet! | 15:01:15 |
Philip Taron (UTC-8) | In reply to @infinisil:matrix.org Philip Taron (UTC-8): I was about to hit enter haha: https://github.com/NixOS/nixpkgs-check-by-name/pull/79#issuecomment-2228713375 All right, it's available for your perusal. | 17:01:45 |
19 Jul 2024 |
infinisil | I'll have the weekly office hour in 5 mins, will take a look at the above there Philip Taron (UTC-8) :) | 17:54:50 |
Philip Taron (UTC-8) | Thanks! I thought I was going to be able to attend but I’m out on an errand at the moment. | 17:55:46 |
infinisil | No worries | 18:01:27 |
infinisil | I'm chilling in https://meet.jit.si/nixpkgs-architecture :) (cc Dominic Mills willbush) | 18:02:03 |
infinisil | Philip Taron (UTC-8): I'm guessing you wouldn't mind if I force pushed on your PR with some small improvements? :P | 18:18:49 |
Philip Taron (UTC-8) | Not at all | 18:54:44 |
infinisil | Ended up doing a separate PR: https://github.com/NixOS/nixpkgs-check-by-name/pull/83 :P | 21:08:58 |
20 Jul 2024 |
| @phileas:asra.gr left the room. | 16:53:50 |
22 Jul 2024 |
| jeremiahs joined the room. | 06:21:45 |
jeremiahs | So @tomberek:matrix.org had pointed me here to talk about an inconsistency I noticed in how nixos handles warnings and assertions. The declaration can be found here: https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/misc/assertions.nix
I am wondering if these can be changed to be more consistent. I had a few ideas of a new way it could be done here is the expected usage:
logs = [
{
# if false the build would fail as prior
assertion = true;
# if false it should show a warning as prior
warnings = true;
message = "";
}
];
in the example above we merge the functionality of assertions and warnings into the data structure of which assertions or warnings must be present to be valid. in addition this could be added in a way as to not break the existing module system but nudge towards a more consistent data structure in the module system. let me know if this makes sense or not.
| 18:13:36 |
infinisil | jeremiahs: Check out https://github.com/NixOS/nixpkgs/pull/97023! | 20:11:36 |