| 10 Aug 2022 |
 Winter (she/her) | that's old! | 16:56:06 |
 nbp | I have been around for a long time, yes, and we still don't have good grafting solutions as of today. | 16:58:22 |
 problems | how does guix do it? iirc they have something equivalent | 16:58:46 |
 Robert Hensing (roberth) | removing .override: https://github.com/nixpkgs-architecture/issues/issues/8 | 16:59:52 |
| Robert Hensing (roberth) | basically moving the package function args into an attrset within the package definition | 17:00:27 |
| Robert Hensing (roberth) | John Ericson: regarding splicing, is it just a matter of calling https://github.com/nixpkgs-architecture/issues/issues/8 with pkgs.splicedPackages for pkgs? | 17:04:21 |
| nbp | In reply to @kity:kity.wtf
how does guix do it? iirc they have something equivalent Packagers are responsible for adding annotation manually for each packages, IIRC. | 17:06:17 |
| nbp | In reply to @kity:kity.wtf
how does guix do it? iirc they have something equivalent * Packagers are responsible for adding annotation manually for each packages, IIRC (from multiples years ago)) | 17:06:30 |
| nbp | * Packagers are responsible for adding annotation manually for each packages, IIRC (from multiples years ago) | 17:06:31 |
| Robert Hensing (roberth) | In reply to @roberthensing:matrix.org
John Ericson: regarding splicing, is it just a matter of calling https://github.com/nixpkgs-architecture/issues/issues/8 with pkgs.splicedPackages for pkgs? I guess that if not, we can make deps special and treat it the same way we treat the callPackage arguments | 17:08:00 |
| Robert Hensing (roberth) | In reply to @roberthensing:matrix.org
John Ericson: regarding splicing, is it just a matter of calling https://github.com/nixpkgs-architecture/issues/issues/8 with pkgs.splicedPackages for pkgs? * I guess that if not, we can make deps special in mkDerivation and treat it the same way we treat the callPackage arguments | 17:08:20 |
| nbp | Robert Hensing (roberth): in SOS, I had suggested to move it to each attribute, such that we can override the attribute set of dependencies using the update operator as well. | 17:09:07 |
| nbp | this definitely add more verbosity at the attribute level :/ | 17:09:45 |
| Robert Hensing (roberth) | you mean at the all-packages.nix level? My proposal removes that need | 17:10:17 |
| nbp | I mean { drvBuilder = stdenv.mkDerivation; deps = { pkgs1 = …; pkgs2 = …; }; installPhase = args: "${args.deps.pkgs1}/bin/foo --help"; … } | 17:12:05 |
| Robert Hensing (roberth) | I think we can pull a trick to rely on function argument reflection once more, as a convenience | 17:14:10 |
| nbp | function argument reflection is best of we avoid it. | 17:16:22 |
| Robert Hensing (roberth) | pkgFun: let
args = functionArgs pkgFun;
deps = do_the_callPacakge_thing args;
in pkgSelf: pkgFun ({ inherit deps } // pkgSelf;
| 17:16:50 |
| Robert Hensing (roberth) | I agree that function reflection is to be avoided, but that's how you reduce the verbosity | 17:17:09 |
| nbp | Well we would no longer require callPackage function either. | 17:17:10 |
| Robert Hensing (roberth) | only for cross compilation splicing, but that could perhaps be solved differently | 17:17:48 |
| Robert Hensing (roberth) | * pkgFun: let
args = functionArgs pkgFun;
deps = do_the_callPacakge_thing args;
in pkgSelf: pkgFun ({ inherit deps } // pkgSelf)
| 17:19:00 |
| Robert Hensing (roberth) | * pkgFun: let
args = functionArgs pkgFun;
deps = do_the_callPacakge_thing args;
in pkgSelf: pkgFun deps ({ inherit deps } // pkgSelf)
| 17:19:27 |
| nbp | myPkgs = import ./myPkgs self;
# myPkgs/default.nix
self:
{
drvBuilder = stdenv.mkDerivation;
deps = { inherit (self) pkgs1 pkgs2; };
config = { doCheck = false; useGit = false; };
…
}
callPackage is used today to provide arguments which are going to be used for various part, such as the stdenv or mkDerivation, the set of dependencies and the configuration flags. While it look nice, having a single overriding strategy which allow to either change the configuration, dependencies or builder the same way as the internals of the builder arguments is interesting too.
| 17:24:06 |
 Alyssa Ross | I do like the idea of separating deps from builder arguments | 17:24:35 |
| Alyssa Ross | Although if we're changing how deps work, I've always wondered about `nativeBuildInputs = pkgs: with pkgs; [ meson ]; buildInputs = pkgs: with pkgs; [ libwhatever ];' | 17:25:21 |
| Alyssa Ross | That way you don't need splicing | 17:25:33 |
| Alyssa Ross | And then outside those, you have to go through buildPackages / hostPackages / etc | 17:25:46 |
| Alyssa Ross | none of this the variable has a different value depending on where it's used effect you get with splicing | 17:26:08 |
 infinisil | (uploaded meeting notes to github: https://github.com/nixpkgs-architecture/meetings/blob/master/2022-08-10.md) | 17:32:41 |
