| 7 Sep 2023 |
DavHau | Its also important if we want to better integrate package updates. We can attach an update script to a package via passthru, but that script needs to know the location of the package definition. Hardcoding the location breaks portability. A mechanism to compute the package location from the attribute path is needed. | 23:10:24 |
DavHau | * Its also important if we want to better integrate package updates. We can attach an update script to a package via passthru, but that script needs to know the location of the package definition. Hardcoding the location breaks portability. A mechanism to compute the package location from the package name is benefitial. | 23:12:44 |
| 8 Sep 2023 |
@piegames:matrix.org | I think currently update scripts are executed in the package's folder, and finding the Nixpkgs root can be done with a simple git command | 06:04:25 |
@piegames:matrix.org | Update scripts should already be invariant to their location | 06:04:49 |
| Alesya Huzik joined the room. | 09:59:01 |
Artturin | When python...callPackage is is gotten rid of everything should be switched to pythonXXPackages instead of python.pkgs. https://github.com/NixOS/nixpkgs/issues/211340 | 10:44:48 |
figsoda | In reply to @infinisil:matrix.org Ah neat! Note that the folder structure should be treated as internal to Nixpkgs, there is no API guarantee that it will not change over time. Considering that, it would be great if we could figure out a proper API that Nixpkgs could expose for this. Maybe it should be as simple as pkgs.preferredDirectoryForPackage "foo" = ./pkgs/by-name/fo/foo just implemented the feature in nix-init, I think one thing that would help is if some constants and shard_for_package are exposed in a crate | 18:34:46 |
tomberek | infinisil: Amazing talk today. Very well done. Bravo! | 22:54:03 |
infinisil | Thanks! ☺️ | 22:55:26 |
infinisil | In reply to @figsoda:matrix.org just implemented the feature in nix-init, I think one thing that would help is if some constants and shard_for_package are exposed in a crate It is internal, but we could maybe just mark it as such. Can you open an issue or a PR to discuss this? | 22:59:40 |
figsoda | In reply to @infinisil:matrix.org It is internal, but we could maybe just mark it as such. Can you open an issue or a PR to discuss this? https://github.com/NixOS/nixpkgs/issues/254122 | 23:06:46 |
figsoda | not much more information aside from what was already said, but this would be a good place to aggregate the discussion | 23:07:27 |
infinisil | figsoda: Can you ping @nixpkgs-architecture/team in the issue so it's going to the teams notifications? That would be great :) | 23:12:53 |
infinisil | Updating it should work | 23:12:58 |
figsoda | updated the issue to ping @nixpkgs-architecture and @nixpkgs-architecture/team since the latter wasn't giving me a preview | 23:15:23 |
infinisil | Ah darn, yeah I think we need to push some people to move the architecture team into the nixos org, because apparently these pings don't work :/ | 23:31:36 |
infinisil | figsoda: So maybe just ping me and @roberth | 23:32:23 |
infinisil | Sorry for the trouble 😅 | 23:32:59 |
figsoda | no worries | 23:37:19 |
| 9 Sep 2023 |
@quantenzitrone:matrix.org | just watched the talk on media.ccc.de
👏👏👏 | 09:20:54 |
| Edward Tjörnhammar joined the room. | 12:37:32 |
| 12 Sep 2023 |
| @cifre:matrix.org joined the room. | 00:44:33 |
@piegames:matrix.org | Just a random idea, what if the automatic migration skipped all packages with open PRs at first to not make any conflicts? Then do one or two more such runs in the hope of catching some more packages, and then the assumption is that everything left is mostly old stuff that is allowed to conflict | 09:03:19 |
Rick (Mindavi) | I thought the migration would take care of that by giving git enough hints? Or doesn't that work (well enough)? | 10:27:54 |
@piegames:matrix.org | Well yes but it still requires rebasing | 10:28:21 |
@piegames:matrix.org | Not sure how many PRs are even affected, and if it's worth it. Just an idea | 10:28:37 |
infinisil | piegames: Hmm yeah I discussed this before, my main argument for not doing this is the complexity of doing so | 10:32:42 |
@piegames:matrix.org | What complexity? (not rhetorical question) | 10:33:14 |
infinisil | I wonder if it's worth it, because rebase PR's should be fairly quick on an individual basis, whereas implementing this requires searching through all PR's (automated of course), and then adding those to an exception list or something, having to decide when to do it anyways | 10:33:49 |
@piegames:matrix.org | Though I'd be interested in some numbers here, like how many pull requests and how many packages are affected by this anyways? How many of these pull requests are younger than three months? | 10:34:49 |