Nixpkgs Architecture Team - Public Room Timeline

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

Load older messages

Sender	Message	Time
8 Jul 2024
infinisil	notashelf: A bit easier is https://github.com/NixOS/nixpkgs/pull/322537, for which it would be best to join #nix-formatting:nixos.org :)	17:22:16
	@ktemkin:katesiria.org left the room.	17:35:52
emily	re "Which files are part of a package?", a reasonable start would be just migrating packages that only have `default.nix` in their directory and nothing else, right?	17:37:15
infinisil	emily: Good idea, that sounds decent!	17:59:00
emily	`emily@yuyuko ~/D/nixpkgs ((8e484a4c))> ls pkgs///default.nix \| wc -l 965 emily@yuyuko ~/D/nixpkgs ((8e484a4c))> for file in pkgs///default.nix; test (count (dirname $file)/*) = 1 && echo x; end \| wc -l 660`	18:10:40
emily	that would work for ~68% of packages	18:10:49
emily	I imagine the rest are mostly divided into "things that vendor something like a `Cargo.toml` or a few patches" and "things that are going to have to be manually migrated anyway"	18:11:25
emily	btw, I assume the intention is to get rid of all the "alternative" `callPackage`/`mkDerivation` analogues at some point so that everything can be by-name?	18:24:10
Philip Taron (UTC-8)	`callPackage` works for a host of things (factories, generators, functions of various sorts) that `pkgs/by-name` rejects -- in particular, the `nixpkgs-check-by-name` tool rejects them.	19:12:58
emily	right; I guess I mean for actual derivations	19:42:07
emily	like Python or Qt stuff	19:42:10
emily	(I would certainly be happy to see those go, as they obviously don't compose)	19:42:30
Philip Taron (UTC-8)	In reply to @philiptaron:matrix.org When I run `maintainers/scripts/check-by-name.sh master` locally in my nixpkgs repository, without any changes, I get this error: `I/O error: Failed to get the definition info for attribute acl: In /tmp/tmp.bQmCobXFGj/merged/pkgs/stdenv/linux/default.nix, attribute parent node is not an attribute path node: NODE_INHERIT@28432..28603` Does anyone else reproduce this? It appears to be about this line in `pkgs/stdenv/linux/default.nix`: `inherit (prevStage) gzip bzip2 xz bash coreutils diffutils findutils gawk gnused gnutar gnugrep gnupatch patchelf attr acl zlib libunistring;` I've opened https://github.com/NixOS/nixpkgs-check-by-name/issues/78 for this issue. Doing some diagnostics now.	20:20:36
Philip Taron (UTC-8)	And https://github.com/NixOS/nixpkgs-check-by-name/pull/79 now too in order to fix it. CC willbush and infinisil .	20:45:05
Qyriad	In reply to @emilazy:matrix.org (I would certainly be happy to see those go, as they obviously don't compose) have you seen the `lib.extendMkDerivation` PR?	20:50:55
emily	nope, thanks for the pointer; subscribed	20:52:12
emily	it seems like it still wouldn't work with the by-name model though	20:52:22
emily	I sort of imagine we want a world where it looks like `stdenv.mkDerivation { mixins = [ qtMixin pythonMixin ]; … }` or something	20:52:50
emily	I guess we could write something like `qtMixin (pythonMixin stdenv.mkDerivation) { … }`?	20:53:04
emily	well, it's really the `callPackage`s that are the problem though, not `mkDerivation`	20:53:17
emily	which gets into splicing stuff that I've never fully understood	20:53:32
Colin	In reply to @emilazy:matrix.org I sort of imagine we want a world where it looks like `stdenv.mkDerivation { mixins = [ qtMixin pythonMixin ]; … }` or something both `buildRustPackage` and `buildPythonPackage` can be replaced with `stdenv.mkDerivation` and adding the appropriate setup hooks to `nativeBuildInputs` (e.g. `cargoSetupHook` or `pypaSetupHook`). i think the `qt5.callPackage` stuff is in a similar state. the Python folk seem very against the idea of replacing `buildPythonPackage` with `mkDerivation`. i think there's more appetite for that on the Rust front.	21:01:05
Colin	In reply to @emilazy:matrix.org I sort of imagine we want a world where it looks like `stdenv.mkDerivation { mixins = [ qtMixin pythonMixin ]; … }` or something * both `buildRustPackage` and `buildPythonPackage` can be replaced with `stdenv.mkDerivation` and adding the appropriate setup hooks to `nativeBuildInputs` (e.g. `cargoSetupHook` or `pypaBuildHook`). i think the `qt5.callPackage` stuff is in a similar state. the Python folk seem very against the idea of replacing `buildPythonPackage` with `mkDerivation`. i think there's more appetite for that on the Rust front.	21:02:59
Qyriad	`buildPythonPackage` very recently became a fair bit more than equivalent to `mkDerivation` with some setup hooks, now that it takes the pythonic `dependencies` and `build-system` arguments and `mkDerivation`-ifies them	21:22:18
9 Jul 2024
emily	right	03:17:17
emily	what about the `callPackage`s? are those "just" the same as `callPackage` that brings another namespace into scope too? I've never been entirely clear on that	03:17:40
tomberek	emily: The `callPackage`s serve the same purpose, but there are minor differences in how some of the package sets are put together due to historical accident. This is why each package set (eg: pythonPackages, rubyPackages, etc) has differing behavior and instructions for use. Standardizing these would be a huge win.	03:53:19
emily	it's always been a little funny to me that Nixpkgs of all things bakes in an assumption that a piece of software uses at most one ecosystem :)	03:54:18
12 Jul 2024
infinisil	I'll be in my weekly office hour again today in 10 minutes: https://meet.jit.si/nixpkgs-architecture :)	17:51:22
infinisil	Ping @willbush:matrix.org @philiptaron:matrix.org @dmills27:matrix.org @raf:notashelf.dev @emilazy:matrix.org in case anybody wants to join :)	17:52:48

Show newer messages

Back to Room ListRoom Version: 9