| 23 Jul 2025 |
 Toma | I'm assuming that some people are using a custom implementation for vendoring. (e.g. for some authentication logic IDK) and their logic assumes that cargoSetupHook expects an unpacked cargo vendor structure.
So I don't think we should unconditionally use fetch-cargo-vendor-util if we detect that cargoDeps is a directory.
We'd have to conditionally run our logic, only when we know we're using something that was generated by fetchCargoVendor
However, we can't really put any distinction marker files into vendor-staging, since that's a FOD.
But maybe I'm overthinking this.
Yes getting rid of the two steps would be healthier for easier overriding of hashes via overrideAttrs
Anyways, I have to go now... I'll be back in an hour or so, sorry!
| 17:59:23 |
 emily | we could expect such users to override it out of the setup hook | 18:00:53 |
| emily | we probably should have added a marker though 😅 | 18:01:04 |
| emily | wait | 18:01:08 |
| emily | can't we just add a passthru.isFetchCargoVendor to fetchCargoVendor | 18:01:17 |
| emily | and add the dep and logic conditionally based on that at eval time? | 18:01:24 |
| emily | based on cargoDeps | 18:01:34 |
| emily | oh the issue is that we don't have access to cargoDeps at that point… | 18:01:39 |
| Toma | Yeah, setup hooks don't know nix values... | 18:03:30 |
| emily | we could condition based on the name | 18:06:12 |
| 25 Jul 2025 |
|  @federicodschonborn:matrix.org changed their display name from Wormy McWormface 🏳️🌈 (he/they) to Cat McFishface 🏳️🌈 (he/they). | 01:43:15 |
| 26 Jul 2025 |
|  oak 🏳️🌈♥️ changed their profile picture. | 08:28:46 |
 niklaskorz | @Toma I rebased + reran your treewide to resolve the merge conflicts, will also run nixpkgs-review for darwin and linux in a bit, but otherwise I think it’s good to go? | 08:46:24 |
| niklaskorz | oh great already new merge conflicts since I rebased 🫠 | 08:47:52 |
| niklaskorz | individual PRs removing useFetchCargoVendor by themselves makes this pretty hard | 08:50:23 |
| niklaskorz | I’d suggest anyone reading here to stop requesting PRs to remove it themselves, except for new packages of course | 08:50:47 |
| Toma | In reply to @niklaskorz:matrix.org
@Toma I rebased + reran your treewide to resolve the merge conflicts, will also run nixpkgs-review for darwin and linux in a bit, but otherwise I think it’s good to go? As discussed earlier, we were considering waiting until https://github.com/NixOS/nixpkgs/pull/423228 gets into stable so that we can do this treewide both on stable and master, to avoid much of the backporting issues.
Though, there hasn't been a staging-next-25.05 cycle since then...
So maybe we can deal with a few backporting conflicts until then.
idk, what do you think is better? | 09:27:40 |
| niklaskorz | my opinion: maintainers are already removing the attribute individually in master, meaning they already have to deal with the backporting conflicts, so I think having the treewide land now is the easier approach to at least have it consistent | 09:29:59 |
 Gaétan Lepage | Can someone from the Rust team (is that a thing?) ACK the PR? I don't feel like merging this beast myself. | 09:30:55 |
| emily | -next-25.05 is due soon | 09:31:19 |
| emily | like within next couple days l | 09:31:28 |
| emily | * | 09:31:34 |
| emily | there's a big security fix | 09:31:38 |
| emily | so if you can wait a week I'd wait a week | 09:31:44 |
| niklaskorz | I see, let’s add that in the treewide PR so it’s documented | 09:32:12 |
| emily | unless it's an emergency. did someone open a tracking issue to remove them all by hand? 😆 | 09:32:13 |
| niklaskorz | will add a comment | 09:32:17 |
| emily | the first time I saw someone nitpicking about a new package set the flag was when I realized we gotta make it warn | 09:32:56 |
| emily | * | 09:33:09 |
| emily | I mean FWIW I'm not strongly against merging into master now | 09:33:45 |
