 | Nixpkgs Architecture Team | 228 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 |
| Nixpkgs Architecture Team | 228 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 |
| Sender | Message | Time |
|---|---|---|
| 13 Jul 2022 | ||
 kevincox | I feel that having an all-packages.nix can't exist for performance reasons because we don't want to parse and evaluate this ever growing file. If you can just resolve an attr into a file and load it you avoid having to load that into memory and the cost is only the definitions of the closure. | 10:38:09 |
| kevincox | I wonder if we need overrides in nixpkgs. Maybe we can give every modified package a name and let the called package use that name. (basically no more I like the look of blueprints but how does this work for user-overrides? | 10:40:56 |
 Gytis Ivaskevicius | I think we should first provide options to not to use overwrites and maybe few years down the line we can remove those alltogether | 10:41:43 |
 K900 | I feel like we need something like overrideAttrs, but stuff like override should be exposed as (args) -> derivation functions | 10:41:54 |
| 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.meI 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.
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.orgMaybe 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 Also for overrides I think we can probably handle this basically the same we do today in 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.orgAt 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* 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.orgAnd 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 |