| 22 May 2025 |
 emily | or is the problem importCargoLock? | 12:24:13 |
| emily | i.e. having to distinguish the two | 12:24:39 |
 Toma | I guess fetchCargoTarball doesnt exist officially anymore | 12:25:26 |
| Toma | So we're more free to assume our own impl | 12:25:40 |
| emily | right | 12:26:46 |
| emily | I don't think the symlink and marker is a bad idea though, but maybe it's not necessary? | 12:26:54 |
| emily | wait, can't we just set a passthru on the FOD? | 12:30:17 |
| emily | to identify it at eval time? | 12:30:21 |
| emily | that doesn't break any hashes | 12:30:23 |
| emily | I guess the problem is that if you're using hooks they can't necessarily see cargoDeps until build | 12:30:37 |
| Toma | we wouldn't break hashes anyway, just APIs | 12:30:43 |
| emily | I guess I don't have a full picture of the problem | 12:31:01 |
| Toma | So the issue with the complete removal of the middle layer, is that then, we'll have fetchCargoVendor spit out our custom vendor-staging FOD, while other users may have assumed the cargoDeps is going to stay as something that is already the final vendor directory.
Now, if we had a marker in the FOD, we could just condition our logic to only trigger if we detect it.
In any case, the symlink solution doesn't sound that bad, if a little bit unnecessary...
| 12:35:50 |
| Toma | * So the issue with the complete removal of the middle layer, is that then we'll have fetchCargoVendor spit out our custom vendor-staging FOD, while other users may have assumed the cargoDeps is going to stay as something that is already the final vendor directory.
Now, if we had a marker in the FOD, we could just condition our logic to only trigger if we detect it.
In any case, the symlink solution doesn't sound that bad, if a little bit unnecessary...
| 12:36:21 |
 Adam Neverwas | Um...i have a kernel driver or what, patch, idk. I should have to add, because my notebook needs it. It's written in rust. | 17:08:15 |
| Adam Neverwas | Sec. | 17:09:38 |
