| 8 Feb 2024 |
 infinisil | On one hand, it can try to automatically migrate as much as possible for https://github.com/NixOS/nixpkgs/pull/211832 | 01:47:59 |
 Philip Taron (UTC-8) | (And yeah, ratchet-style checks are always set up to make autofix easier than the pass/fail linters.) | 01:48:14 |
| infinisil | Which then also means people can reproduce that PR and don't have to review it entirely | 01:48:20 |
| infinisil | But also, some things can't be migrated automatically, but the tool can give you a hint what needs to be done manually | 01:48:46 |
| infinisil | So you can use this to generate a TODO list to complete the migration! | 01:49:17 |
| 13 Feb 2024 |
 9999years | it would be nice to have a "generic" variant of lib.makeOverridable that uses a different attribute name, to replace functions like overrideCabal and overridePythonAttrs, and to make it easier to write equivalent functions for other derivation-creation-functions.
here's my sketch of an implementation, i think it's 80% or 90% of the way there but it doesn't quite work. the code makes my head hurt. i'm done for the day but others might be interested in trying to get this working
https://github.com/NixOS/nixpkgs/pull/288431
| 01:28:24 |
| 9999years | in the meantime, i've got a copy/paste of lib.makeOverridable into the rust packaging functions to make it possible to override cargoHash and similar attributes (currently it's basically impossible to upgrade a rust package's version in an overrideAttrs function)
https://github.com/NixOS/nixpkgs/pull/288430 | 01:29:31 |
| 9999years | i was also somewhat disappointed to realize that the code for overrideCabal and overridePythonAttrs are very different, despite accomplishing basically the same thing. this lack of consistency makes it very challenging to move from one part of the nixpkgs codebase to another | 01:30:19 |
 tomberek | Standardize the package sets! https://github.com/nixpkgs-architecture/issues/issues/21 | 02:24:01 |
 toonn | Yes, please. Yesterday, rather than today. | 11:03:54 |
| toonn | This is the only reason I've been looking at dream2nix. | 11:04:10 |
| 9999years | what's blocking this PR? it seems like most of the comments are pretty minor
https://github.com/NixOS/nixpkgs/pull/234651 | 17:28:53 |
 Alyssa Ross | well the merge conflicts can't be helping | 17:58:30 |
| infinisil | I should really take a look at that PR, but it's really hard to get motivated for that :/ | 18:18:46 |
| infinisil | I generally want to invest my time into fixing the root of problems, and I'm not really convinced that's it. | 18:19:46 |
| infinisil | * I generally want to invest my time into fixing the root of problems, and I'm not really convinced that PR's a case of that | 18:19:59 |
| infinisil | 9999years: ^ | 18:20:01 |
| infinisil | it might be though, I need to take a closer look | 18:21:12 |
| infinisil | Same for your new PR (https://github.com/NixOS/nixpkgs/pull/288431) | 18:21:55 |
| 14 Feb 2024 |
|  @syphoxy:matrix.org changed their display name from sy to Stalled Engine. | 13:06:09 |
 Alexandros Liarokapis | Hi all. After much experimentation, I managed to add support for cross building using the precompiled "gcc-arm-embedded" toolchain. This includes taking care of the ccWrapper and binutilsWrapper. In order to avoid actually building gcc from source I had to use replaceStdenvStages and share the cross stages but change the last stage. Maybe it would be useful to add support upstream? It is non-trivial but very useful since it avoids building the toolchain for each difelferent arm-none-eabi configuration and the toolchain is already cached. The ideal way forward would perhaps be to add proper multilib support when cross building for many configurations like arm does with its toolchain. Is any of this worth considering for upstreaming to nixpkgs? | 15:54:39 |
| Alexandros Liarokapis | * Hi all. After much experimentation, I managed to add support for cross building using the precompiled "gcc-arm-embedded" toolchain. This includes taking care of the ccWrapper and binutilsWrapper. In order to avoid actually building gcc from source I had to use replaceStdenvStages and share the cross stages except the last one and properly handle float abis naming conventions and more. Maybe it would be useful to add support upstream? It is non-trivial but very useful since it avoids building the toolchain for each difelferent arm-none-eabi configuration and the toolchain is already cached. The ideal way forward would perhaps be to add proper multilib support when cross building for many configurations like arm does with its toolchain. Is any of this worth considering for upstreaming to nixpkgs? | 15:55:57 |
| infinisil | Ping John Ericson ^ | 16:39:44 |
 @qyriad:matrix.org | infinisil: what kind of solution would you prefer? re extendMkDerivation | 16:41:57 |
| infinisil | Qyriad: A solution that unifies existing approaches in a way as backwards compatible as possible, along with a plan on how the existing approaches can be cleaned up | 16:43:45 |
| infinisil | I guess in short: Making solutions converge instead of diverge (just adding more alternate approaches) | 16:44:49 |
| infinisil | * I guess in short: Making solutions converge (unifying and cleaning up approaches) instead of diverge (just adding more alternate approaches) | 16:45:05 |
| infinisil | This takes a whole bunch more effort, but is ultimately what we need to actually clean up Nixpkgs | 16:46:26 |
| @qyriad:matrix.org | is extendMkDerivation not a step in that direction though? it adds API surface but would reduce the complexity for the existing alternate approaches | 16:50:18 |
| 9999years | yeah being able to get the functionality of overridePythonAttrs and overrideCabal in the existing overrideAttrs function is very appealing | 16:53:33 |
