Nixpkgs Architecture Team - Public Room Timeline

	Nixpkgs Architecture Team	226 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 Jul 2022
kevincox	I think we need to provide user overrides. For example I use a custom libvte in my system and it is important to me that all packages pick that up.	10:42:56
Gytis Ivaskevicius	In reply to @k900:0upti.me I feel like we need something like `overrideAttrs`, but stuff like `override` should be exposed as (args) -> derivation functions I would like to try to push concept as 'blueprints' (link above) as a native nix structure. First we need to implement it on multiple flakes and see how community reacts	10:43:32
Gytis Ivaskevicius	and its basically what you are looking for	10:43:51
Gytis Ivaskevicius	how would one go about benchmarking `all-packages.nix` so first step would be to remove all lines with `callPackage`, then setup some autodetection logic, but then what?	10:46:32
Gytis Ivaskevicius	whats the proper benchmark scenario?	10:46:44
Gytis Ivaskevicius	building one package?	10:47:01
kevincox	I think there are probably two main scenarios. Building a small closure with only a few deps. Building a large closure (a full-featured desktop NixOS system with lots of packages installed?) I think having all-packages.nix probably doesn't hurt 2 much but costs 1 a lot.	11:15:24
Gytis Ivaskevicius	I dont see how second scenario differs. we should see the same performance change	11:30:40
kevincox	1 Benefits from lower fixed-cost overhead while 2 benefits from lower per-lookup overhead.	11:32:36
Gytis Ivaskevicius	I feel dumb suggesting this but how does it sound to have a folder for each letter of alphabeth and place projects depending on the letter they start with 😄	12:21:51
Gytis Ivaskevicius	thats a 'fix' for github 1000 files limit	12:22:14
infinisil	Gytis Ivaskevicius: This was discussed a bunch if you scroll up :)	12:22:33
Gytis Ivaskevicius	ah great, at least im not the only one considering that 😄	12:22:59
infinisil	Another idea I played around with is to extend the notion of packages and their versions. One of the goals of it is to clean up handling of versions, aka getting rid of the `python`, `python2`, `python27`, `ffmpeg`, `ffmpeg_full`, etc. inconsistencies	12:33:51
infinisil	Main idea is to allow each package name to be associated with arbitrarily many versions. The interface might look something like `python` (default), `python.version "2"`, `python.version "2.7"`, `ffmpeg`, `ffmpeg.version "full"`	12:35:24
kevincox	In reply to @infinisil:matrix.org Another idea I played around with is to extend the notion of packages and their versions. One of the goals of it is to clean up handling of versions, aka getting rid of the `python`, `python2`, `python27`, `ffmpeg`, `ffmpeg_full`, etc. inconsistencies Maybe I lack creativity but I think that would be a different project. For now they will just end up in `python.nix`, `python2.nix`... Those files could just be trivial import stubs.	12:35:34
infinisil	Well it is another idea, but it plays into the above ideas, let me explain a bit more	12:36:19
infinisil	As implied with the "full", this can go a bit further, versions don't need to be a single string, but it can be something more abstract. A version could be a combination of: Multiple forks of a project, multiple semantic versions, different variants and more	12:38:01
kevincox	In reply to @kevincox:matrix.org I think we need to provide user overrides. For example I use a custom libvte in my system and it is important to me that all packages pick that up. Also for overrides I think we can probably handle this basically the same we do today in `all-packages.nix` for now. We can think about changing those as a different project. For now it could look something like: `# foo.nix {pkgs}: pkgs.callPackage foo/impl.nix { python = pkgs.python27 }` That isn't the prettiest but allows us to do overrides and maintains the current API. Then I think we can probably clean it up as a separate effort if we wanted too. Unless I am also missing a way that merging both projects returns a better result here.	12:38:22
kevincox	In reply to @infinisil:matrix.org As implied with the "full", this can go a bit further, versions don't need to be a single string, but it can be something more abstract. A version could be a combination of: Multiple forks of a project, multiple semantic versions, different variants and more At this point how is this different from regular package arguments that can be overridden? Sounds like you can have `python.override { version = "2.7" }` if we anted to.	12:39:48
kevincox	In reply to @infinisil:matrix.org As implied with the "full", this can go a bit further, versions don't need to be a single string, but it can be something more abstract. A version could be a combination of: Multiple forks of a project, multiple semantic versions, different variants and more * At this point how is this different from regular package arguments that can be overridden? Sounds like you can have `python.override { version = "2.7" }` if we wanted to.	12:39:52
infinisil	In reply to @infinisil:matrix.org As implied with the "full", this can go a bit further, versions don't need to be a single string, but it can be something more abstract. A version could be a combination of: Multiple forks of a project, multiple semantic versions, different variants and more And if we go even further, this can solve the problem of multiple projects having the same name, or projects renaming themselves: If two projects have the same name, in this new model this can be modeled as two versions of the same package. So this means that when there's two projects with the same name, they would both be accessible under `pkgs.someName`, but you then have to explicitly choose a version (no default)	12:40:43
infinisil	And when a project gets renamed, it can be represented under two names, `pkgs.oldName` and `pkgs.newName`, but underneath it can be the same thing, and share its name with other projects of the same name	12:41:29
kevincox	One question that raises is what does hydra build? Right now hydra builds basically anything with a name. If you force a version argument then hydra won't build anything.	12:41:56
infinisil	This then ties a bit more into the whole "automating attributes from the file structure"	12:41:58
infinisil	kevincox: That won't be a problem, what hydra builds can be changed, needs some new conventions for that	12:42:51
infinisil	In reply to @kevincox:matrix.org Also for overrides I think we can probably handle this basically the same we do today in `all-packages.nix` for now. We can think about changing those as a different project. For now it could look something like: `# foo.nix {pkgs}: pkgs.callPackage foo/impl.nix { python = pkgs.python27 }` That isn't the prettiest but allows us to do overrides and maintains the current API. Then I think we can probably clean it up as a separate effort if we wanted too. Unless I am also missing a way that merging both projects returns a better result here. (I like that idea btw)	12:43:39
profpatsch	I feel like many people here are rediscovering that an attrset and a function are synonymous things :P	12:44:40
infinisil	Oh also, this whole versioning thing then also ties into distributing nixpkgs, because it could allow third-party repos to add to the supported versions in a composition-friendly way. It also ties into allowing users to select specific versions in a generic way	12:45:06
infinisil	profpatsch: Well, sometimes at least	12:46:15

Show newer messages

Back to Room ListRoom Version: 9