Nixpkgs Architecture Team - Public Room Timeline

	Nixpkgs Architecture Team	232 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
5 Feb 2023
@blaggacao:matrix.org	^^ which is btw, why I thing your work in the NAT is so powerful.	18:53:23
infinisil	The jumble of GitHub + Matrix + Discourse might not be the best, yes :P	18:56:36
infinisil	Still looking for more shepherds for https://github.com/NixOS/rfcs/pull/138 btw ;)	18:58:55
Winter (she/her)	What would a shepherd actually do for such an RFC, @infinisil?	19:02:50
Winter (she/her)	e.g. what is there to shepherd?	19:02:58
infinisil	Winter (she/her): https://github.com/NixOS/rfcs#shepherd-team	19:03:49
@blaggacao:matrix.org	Make a meeting and call for FCP, essentially? 😃	19:04:05
Winter (she/her)	Ah, I see.	19:04:21
infinisil	Arguably someone from the steering committee should also be a shepherd member, because they are "codeowners"	19:05:04
Winter (she/her)	Agreed -- maybe write that in the comments?	19:05:59
Winter (she/her)	* Agreed -- maybe write that in the comments, so they can see?	19:06:03
@blaggacao:matrix.org	For what it's worth now or later, I packages frappe/bench so interested parties could start playing around with `gameplan`, should they wish to.	19:21:51
@blaggacao:matrix.org	Thanks to ChatGPT for Nixpkgs this was super easy. 😃	19:22:32
@blaggacao:matrix.org	* For what it's worth now or later, I packaged frappe/bench so interested parties could start playing around with `gameplan`, should they wish to.	19:23:11
@blaggacao:matrix.org	In fact, in the spirit of RFC 140, the hardest part was to find the right folder (and some version overrides, to be honest).	19:27:06
@blaggacao:matrix.org	It just got harder and became an evangelization issue after playing a little with it. But that's borderline off topic, here, anyways.	23:42:32
6 Feb 2023
Gytis Ivaskevicius	Hey guys, not sure what you guys are up to these days but I'd appreciate if you guys could follow up on this `blueprints` idea, maybe making it a standard in nix ecosystem https://github.com/NixOS/nixpkgs/pull/208020#issuecomment-1419168718	14:29:54
figsoda	In reply to @gytis-ivaskevicius:matrix.org Hey guys, not sure what you guys are up to these days but I'd appreciate if you guys could follow up on this `blueprints` idea, maybe making it a standard in nix ecosystem https://github.com/NixOS/nixpkgs/pull/208020#issuecomment-1419168718 The blueprints still looks very nixpkgs-esque to me I believe that we should not encourage people to depend on nixpkgs and this should be resolved in nix itself. I can see a `callPackage` like pattern being lifted to the `nix` level (maybe in a separate repository `core`, kind of like nixpkgs.lib), but things like `stdenv` are strictly nixpkgs, it breaking change in nixpkgs will cause this flake to break, and I'm not seeing anything that refers to nixpkgs in the flake outputs. about the issue, I like the `perSystem` pattern that flake-parts uses, maybe this can be supported in a more official way (something in nixpkgs like `nixosSystem`, or even ootb flakes support)	14:56:25
figsoda	In reply to @gytis-ivaskevicius:matrix.org Hey guys, not sure what you guys are up to these days but I'd appreciate if you guys could follow up on this `blueprints` idea, maybe making it a standard in nix ecosystem https://github.com/NixOS/nixpkgs/pull/208020#issuecomment-1419168718 * The blueprints still looks very nixpkgs-esque to me I believe that we should not encourage people to depend on nixpkgs and this should be resolved in nix itself. I can see a `callPackage` like pattern being lifted to the `nix` level (maybe in a separate repository `core`, kind of like nixpkgs.lib), but things like `stdenv` are strictly nixpkgs, it having a breaking change in nixpkgs will cause this flake to break, and I'm not seeing anything that refers to nixpkgs in the flake outputs. about the issue, I like the `perSystem` pattern that flake-parts uses, maybe this can be supported in a more official way (something in nixpkgs like `nixosSystem`, or even ootb flakes support)	14:59:45
figsoda	* The blueprints still looks very nixpkgs-esque to me I believe that we should not encourage people to depend on nixpkgs and this should be resolved in nix itself. I can see a `callPackage` like pattern being lifted to the `nix` level (maybe in a separate repository `core`, kind of like nixpkgs.lib), but things like `stdenv` are strictly nixpkgs, it having a breaking change in nixpkgs will cause this flake to break, and I'm not seeing anything that refers to nixpkgs in the flake outputs. about the issue, I like the `perSystem` pattern that flake-parts uses, maybe this can be supported in a more official way (something in nixpkgs like `nixosSystem`, or even ootb support in nix)	15:02:43
infinisil	@room: The next meeting will take place in ~10 minutes, we'll be there to discuss RFC 140 - meeting link - live stream - meeting notes	15:21:39
Gytis Ivaskevicius	I can see a callPackage like pattern being lifted to the nix level (maybe in a separate repository core, kind of like nixpkgs.lib), but things like stdenv are strictly nixpkgs, it having a breaking change in nixpkgs will cause this flake to break, and I'm not seeing anything that refers to nixpkgs in the flake outputs. No, I think this should stay part of nixpkgs. Just that users have a fool proof option to make package depend on whichever nixpkgs revision they feel like about the issue, I like the perSystem pattern that flake-parts uses, maybe this can be supported in a more official way (something in nixpkgs like nixosSystem, or even ootb support in nix) `perSystem` is not part of the idea, it's being addressed as a separate issue. Quite possibly differently	15:23:02
nbp	In reply to @figsoda:matrix.org The blueprints still looks very nixpkgs-esque to me I believe that we should not encourage people to depend on nixpkgs and this should be resolved in nix itself. I can see a `callPackage` like pattern being lifted to the `nix` level (maybe in a separate repository `core`, kind of like nixpkgs.lib), but things like `stdenv` are strictly nixpkgs, it having a breaking change in nixpkgs will cause this flake to break, and I'm not seeing anything that refers to nixpkgs in the flake outputs. about the issue, I like the `perSystem` pattern that flake-parts uses, maybe this can be supported in a more official way (something in nixpkgs like `nixosSystem`, or even ootb support in nix) Let's hope not, as my plan was to get rid of its crappy logic to make it trivially extensible.	15:25:10
infinisil	In reply to @gytis-ivaskevicius:matrix.org Hey guys, not sure what you guys are up to these days but I'd appreciate if you guys could follow up on this `blueprints` idea, maybe making it a standard in nix ecosystem https://github.com/NixOS/nixpkgs/pull/208020#issuecomment-1419168718 We're currently focusing on RFC 140 as the first major change, but after that's done and implemented we'll have to find the next thing to work on, which might be something from the future work section, from the other NAT issues or something else	15:26:09
infinisil	There was also a discussion yesterday about parallelising the work more	15:26:34
infinisil	I think it all hinges on making that first RFC a success though	15:27:56
growpotkin1	A fool proof way to depend on a particular version is a pinned form of Nixpkgs in a flake. You can pin an arbitrary number and create an overlay to cherry pick.	15:30:15
growpotkin1	Override is your friend also	15:31:01
infinisil	Ehh, overlays and overrides have serious composability problems, I really think we need something better to replace them	15:31:22
infinisil	John Ericson Robert Hensing (roberth) tomberek: Joining?	15:32:26

Show newer messages

Back to Room ListRoom Version: 9