| 22 May 2025 |
 emily | that way nothing gets persisted | 12:16:47 |
 Toma | It would be better. Though we'd need some interesting workarounds...
An interesting option would be to have the non-FOD part jus be a directory with a symlink to the FOD and a marker file that the hook can detect. | 12:19:40 |
| Toma | * It would be better. Though we'd need some interesting workarounds...
An interesting option would be to have the non-FOD part just be a directory with a symlink to the FOD and a marker file that the hook can detect. | 12:19:59 |
| Toma | Ideally we'd get rid of the double layering, but I don't know how viable that is really at this point... (It's not backportable, there are no marker files in the FOD part, except maybe the way the directories were named) | 12:22:39 |
| emily | what kind of workarounds? | 12:23:28 |
| emily | we can get rid of the double layering if we remove the intermediate derivation, right? | 12:23:50 |
| emily | because it will always be the FOD | 12:24:09 |
| 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 |
