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
8 Jul 2024
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
14 Jul 2024
Philip Taron (UTC-8)	In reply to @infinisil:matrix.org I'll be in my weekly office hour again today in 10 minutes: https://meet.jit.si/nixpkgs-architecture :) I plan on attending this coming week, as I will be at home as opposed to travelling.	23:48:26
15 Jul 2024
Philip Taron (UTC-8)	infinisil: I'm blocked on adding the regression test you asked for in #79 by failing to understand how to ask Nix for the line/position numbers.	15:00:22
infinisil	Philip Taron (UTC-8): I was about to hit enter haha: https://github.com/NixOS/nixpkgs-check-by-name/pull/79#issuecomment-2228713375	15:01:02
Philip Taron (UTC-8)	Sweet!	15:01:15
Philip Taron (UTC-8)	In reply to @infinisil:matrix.org Philip Taron (UTC-8): I was about to hit enter haha: https://github.com/NixOS/nixpkgs-check-by-name/pull/79#issuecomment-2228713375 All right, it's available for your perusal.	17:01:45

Show newer messages

Back to Room ListRoom Version: 9