!OqhvaDMJdKYUicLDiE:nixos.org

Nixpkgs Stdenv

215 Members
69 Servers

Load older messages


SenderMessageTime
7 Jan 2025
@tomasajt:matrix.orgToma now that I think about it, self, (which I think means finalAttrs.finalPackage) contains everything that finalAttrs does so in theory we could just skip giving access to finalAttrs, but it might make it more confusing 00:27:21
@emilazy:matrix.orgemily (though actually I'd be somewhat tempted to make it a new by-name interface – like package2.nix is just the { self, pkgsOnHost, ... }: … part and the mkPackage is implicit) 00:27:43
@emilazy:matrix.orgemily (that way you eliminate the extra layer of { lib, mkDerivation2 }: and never make the terrible mistake of getting a spliced package from that level) 00:28:00
@emilazy:matrix.orgemily I was actually thinking of it just as a less verbose name for finalAttrs, but that might work too :) 00:28:20
@tomasajt:matrix.orgTomayeah maybe, though we always have to make sure non nixpkgs users can healthily consume single file package definitions00:29:08
@emilazy:matrix.orgemily (I was really happy when I thought of this because it's an excuse to use inherit rather than with with explicit package sets that also happens to solve a major overrides pain point) 00:29:23
@emilazy:matrix.orgemily (it happens quite a lot that you pick some specific package variant in your dependencies header and that causes override issues, being able to define the interface locally is really nice since all-packages.nix action at a distance sucks and gets in the way of by-name) 00:29:56
@tomasajt:matrix.orgToma* yeah maybe, though we always have to make sure non-nixpkgs consumers of mkDerivation2 can healthily use it00:30:03
@emilazy:matrix.orgemily callPackage2 :p 00:30:09
@tomasajt:matrix.orgTomaheh00:30:14
@emilazy:matrix.orgemily I mean mkDerivation2 is basically doing the job of callPackage 00:30:36
@tomasajt:matrix.orgTomaanyways I really have to go to sleep now, I messed up my schedule implementing this, bye!!00:30:40
@emilazy:matrix.orgemilysince it is also handling overrides00:30:40
@emilazy:matrix.orgemily(*in the form I want it to be at least)00:30:45
@emilazy:matrix.orgemilysleep well :)00:30:51
@emilazy:matrix.orgemilysorry for the deluge of immediate feedback I've been thinking about this for too long00:31:02
@tomasajt:matrix.orgToma

Updated the POC to include some deps/depsInPath examples.
It is not part of mkDerivation2, but implemented per-package, currently.

Also, since we don't use callPackage path {}, but import path pkgs the should be no splicing involved.

(though we might get a spliced package through an override. what to do about that....)

Also removed the ability to override __pkgs so now we don't have to use finalAttrs.__pkgs if we know the package's package set.

08:54:16
@tomasajt:matrix.orgToma* Updated the POC to include some deps/depsInPath examples. It is not part of mkDerivation2, but implemented per-package, currently. Also, since we don't use callPackage path {}, but import path pkgs there should be no splicing involved. (though we might get a spliced package through an override. what to do about that....) Also removed the ability to override __pkgs so now we don't have to use finalAttrs.__pkgs if we know the package's package set. 09:12:35
@tomasajt:matrix.orgToma* Updated the POC to include some deps/depsInPath examples. It is not part of mkDerivation2, but implemented per-package, currently. Also, since we don't use `callPackage path {}`, but `import path pkgs` there should be no splicing involved. (though we might get a spliced package through an override. what to do about that....) Also removed the ability to override __pkgs so now we don't have to use finalAttrs.__pkgs if we know the package's package set. 09:13:19
10 Jan 2025
@xanderio:bitflip.jetztxanderio joined the room.09:16:03
11 Jan 2025
@pandapip1:matrix.orgpandapip1 joined the room.21:21:04
13 Jan 2025
@tomasajt:matrix.orgTomaUpdated my POC https://github.com/NixOS/nixpkgs/pull/37161301:15:33
@tomasajt:matrix.orgToma it is defined in terms of layers (the list of layers is currently static, but should be pretty straightforward to make extendible to be used by things like buildRustPackage.
and also finalAttrs is now actually the same as finalPackage
the cross stuff is not better than a few days ago, but I have at least read the splicing and bootstrapping implementations, which should help me
01:16:08
@tomasajt:matrix.orgToma * it is defined in terms of layers (the list of layers is currently static, but should be pretty straightforward to make extendible to be used by things like buildRustPackage.)
and also finalAttrs is now actually the same as finalPackage
the cross stuff is not better than a few days ago, but I have at least read the splicing and bootstrapping implementations, which should help me
01:16:28
@emilazy:matrix.orgemily fwiw finalAttrs.finalPackage.doCheckfinalAttrs.doCheck 01:20:23
@emilazy:matrix.orgemily finalPackage has post-processing 01:20:37
@emilazy:matrix.orgemilyand ideally splicing would be totally irrelevant to a new construct :)01:20:58
@emilazy:matrix.orgemilyit's only there as a hack for backwards compatibility01:21:01
@tomasajt:matrix.orgToma
In reply to @emilazy:matrix.org
fwiw finalAttrs.finalPackage.doCheckfinalAttrs.doCheck
well, it is the same now, since finalAttrs = finalPackage
The fix point IS the package
01:30:49
@emilazy:matrix.orgemily how do you handle doCheck then? 01:31:02

Show newer messages


Back to Room ListRoom Version: 9