!djTaTBQyWEPRQxrPTb:nixos.org

Nixpkgs Architecture

216 Members
Discussions about Nixpkgs' architecture - https://github.com/NixOS/nixpkgs/labels/architecture47 Servers

Load older messages

SenderMessageTime
13 Dec 2023
@roberthensing:matrix.orgRobert Hensing (roberth) My proposal is smaller in scope, keeping mkDerivation-like calls in top-level and such. It only tries to solve problems within a single package. 12:04:58
@roberthensing:matrix.orgRobert 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:mozilla.orgnbpOh … 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
@roberthensing:matrix.orgRobert 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:mozilla.orgnbp 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:mozilla.orgnbpThe 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
@roberthensing:matrix.orgRobert 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
@roberthensing:matrix.orgRobert Hensing (roberth)Added that to the issue text as well15:38:14
@roberthensing:matrix.orgRobert Hensing (roberth) * Added that to the issue text as well just now15:38:21
@infinisil:matrix.orginfinisil nbp: That actually reminds me of https://nixos.org/manual/nixpkgs/stable/#function-library-lib.attrsets.updateManyAttrsByPath 16:05:14
@9999years:matrix.org9999years joined the room.20:23:53
@9999years:matrix.org9999years

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:matrix.orginfinisil 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:matrix.orginfinisil 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:matrix.orginfinisil Or a meta.nix, which would allow querying package metadata without much evaluation 23:48:39
@infinisil:matrix.orginfinisil 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:matrix.orginfinisil 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:matrix.orginfinisilAnd yes this does sound a lot like the Flakes output schema, but I don't think we can use that directly in its current state23:52:56
@infinisil:matrix.orginfinisil 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:matrix.org9999years 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:matrix.orginfinisil Not sure what you mean by merging it with callPackage 00:14:38
@9999years:matrix.org9999years

i.e. merging #270537 with { callPackage, ... }: as the argument, and then later doing something like

{
  callPackage,
}:
00:18:17
@9999years:matrix.org9999years *

i.e. merging #270537 with { callPackage, ... }: as the argument, and then later doing something like

{
  callPackage,
  packageFromDirectory ? path: callPackage path {},
}:
00:18:32
@infinisil:matrix.orginfinisil
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:matrix.orginfinisil
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:matrix.orginfinisil
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:matrix.orginfinisil 9999years: Posted a comment: https://github.com/NixOS/nixpkgs/pull/270537#discussion_r1426132656 03:24:34
@infinisil:matrix.orginfinisil
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
@philiptaron:matrix.orgPhilip 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
@philiptaron:matrix.orgPhilip Taron (UTC-8)Redacted or Malformed Event03:46:37

Show newer messages

Back to Room ListRoom Version: 9