Nixpkgs Architecture Team - Public Room Timeline

	Nixpkgs Architecture Team	229 Members
	https://github.com/nixpkgs-architecture, weekly public meetings on Wednesday 15:00-16:00 UTC at https://meet.jit.si/nixpkgs-architecture	53 Servers

Load older messages

Sender	Message	Time
13 Dec 2023
Robert Hensing (roberth)	My proposal solves the problem of too many layers of abstraction, not the problem of override memory consumption or anything related to top-level. Nonetheless it may unify how packages are constructed, having less diverse calls in top-level etc, so it could be a stepping stone towards S.O.S.	12:11:59
nbp	Oh … I completely misunderstood the proposal :/ Which is about using the module system -like to update the content of a derivation, and not to update Nixpkgs. Sorry, I would have to re-read based on this expectation.	14:38:13
Robert Hensing (roberth)	Don't worry. We don't normally talk about layers at the individual package level, so I can see why you associated it that way. (Also the proposal is to remove the ad hoc and excessive layering, so that word is kind of on the way out I guess - just useful for describing the current situation and the transition)	15:09:49
nbp	one idea of light weight merging which is almost what S.O.S. suggested would be to have a `zipWithRightMergeFun`, if the right hand side is a function, then this is considered to be a merging function. Then replacing is `_: newValue`, appending is `old: old + "exit 0"`, debugging is `x: __trace x x`	15:19:03
nbp	The problem is that this is per-value, and thus we lose the recurisve attribute sets, where one define the result based on another attribute. This could still be provided through the final resume-point, assuming that the resolver is at the end of Nixpkgs.	15:21:13
Robert Hensing (roberth)	The exact merging semantics is to be decided. It will be easier when we have a prototype that we can benchmark and play around with.	15:36:58
Robert Hensing (roberth)	Added that to the issue text as well	15:38:14
Robert Hensing (roberth)	* Added that to the issue text as well just now	15:38:21
infinisil	nbp: That actually reminds me of https://nixos.org/manual/nixpkgs/stable/#function-library-lib.attrsets.updateManyAttrsByPath	16:05:14
	9999years joined the room.	20:23:53
9999years	should RFC 140 be a mechanism just for nixpkgs (which has fairly unique requirements, like being large enough to necessitate sharding package names) or should it also be a user-facing mechanism for creating package sets from directories? i'd like to add a user-facing mechanism for creating package sets from directories (#270537) and infinisil hasn't been sure whether or not it should be the same mechanism as `pkgs/by-name`. i'd like to make a decision on this so that we can ship something, and then we can iterate and improve from there	20:27:16
infinisil	9999years: A big future idea with RFC 140 was to use the package directories for more than just the package definition itself.	23:47:57
infinisil	So we could have e.g. a `module.nix` file that specifies a NixOS module (or home-manager module, or some abstract module, ..)	23:48:21
infinisil	Or a `meta.nix`, which would allow querying package metadata without much evaluation	23:48:39
infinisil	Or some way to specify overrides. `args.nix` maybe, but that's very ad-hoc. Maybe rather something like `dependencies.nix` and `config.nix` or so	23:49:34
infinisil	And this kind of idea would be really useful to have standardised, such that people can write third-party package directories, and upstreaming to Nixpkgs will be just a matter of a `cp -r`. Or even better: Allow third-party repositories to have their package directories be automatically pulled into Nixpkgs	23:50:38
infinisil	And yes this does sound a lot like the Flakes output schema, but I don't think we can use that directly in its current state	23:52:56
infinisil	9999years: But yeah, having https://github.com/NixOS/nixpkgs/pull/270537 won't prevent such a standardisation in the future. I don't think new approaches should be introduced when there's already an existing one. But in this case there isn't an existing approach, so I don't want to block that.	23:56:37
14 Dec 2023
9999years	maybe we could merge it with `callPackage` and then adapt it to use `packageFromDirectory` in the future (and add an `assert` that only one is supplied)...?	00:02:34
infinisil	Not sure what you mean by merging it with `callPackage`	00:14:38
9999years	i.e. merging #270537 with `{ callPackage, ... }:` as the argument, and then later doing something like `{ callPackage, }:`	00:18:17
9999years	* i.e. merging #270537 with `{ callPackage, ... }:` as the argument, and then later doing something like `{ callPackage, packageFromDirectory ? path: callPackage path {}, }:`	00:18:32
infinisil	In reply to @philiptaron:matrix.org infinisil: I love `pkgs/by-name` and I write Rust at work. I'd be glad to be code reviewer when you're ready. I just cleaned up the PR and marked it as ready to review, it would be great if you could take a look now! Best reviewed commit-by-commit, they all come with comments: https://github.com/NixOS/nixpkgs/pull/272395	03:10:34
infinisil	In reply to @philiptaron:matrix.org infinisil: I love `pkgs/by-name` and I write Rust at work. I'd be glad to be code reviewer when you're ready. * I just cleaned up the PR and marked it as ready to review, it would be great if you could take a look now! Best reviewed commit-by-commit, they all come with commit messages: https://github.com/NixOS/nixpkgs/pull/272395	03:14:08
infinisil	In reply to @9999years:matrix.org i.e. merging #270537 with `{ callPackage, ... }:` as the argument, and then later doing something like `{ callPackage, packageFromDirectory ? path: callPackage path {}, }:` Hmm not sure. The reason why I proposed `packageFromDirectory` is to make the function interface not more complicated than it has to be. But yeah I can see the argument that `callPackage` is fairly well-known, so it might be nice to have that as an argument, even though the second argument doesn't really make sense for the function as is.	03:17:57
infinisil	9999years: Posted a comment: https://github.com/NixOS/nixpkgs/pull/270537#discussion_r1426132656	03:24:34
infinisil	In reply to @infinisil:matrix.org I just cleaned up the PR and marked it as ready to review, it would be great if you could take a look now! Best reviewed commit-by-commit, they all come with commit messages: https://github.com/NixOS/nixpkgs/pull/272395 We could also pair-review this on a call if you want. Also I think Wanja Hentze might be interested in taking a look	03:41:10
Philip Taron (UTC-8)	Taking a look. I could pair review on a call. It's 19:45 PST and I'm available for another 45 minutes. :-)	03:46:28
Philip Taron (UTC-8)	Redacted or Malformed Event	03:46:37
Philip Taron (UTC-8)	* I've got Zoom if that works for you.	03:47:06

Show newer messages

Back to Room ListRoom Version: 9