| 11 Aug 2024 |
 Gaétan Lepage | Thanks ! I'll try this :) | 13:24:05 |
| 12 Aug 2024 |
|  @amiablechief:matrix.org left the room. | 11:34:32 |
 emily | 2024 rust goals: | 18:36:15 |
| emily | 
Download image.png | 18:36:19 |
| emily | (https://rust-lang.github.io/rust-project-goals/2024h2/accepted.html) | 18:36:20 |
| emily | maybe we can dylib it up by 2025 :) | 18:36:30 |
 522 | yeah i have CARGO_TARGET_DIR set for this, but it definitely is a bit hacky | 18:37:20 |
| emily | we were talking about actually building crates once in separate derivations without having to replace Cargo entirely the other day | 18:38:05 |
| 522 | (2 binaries with the same name in different places will alias, so running one may actually run the other, depending on which was built first) | 18:38:11 |
| emily | and it seemed like Cargo just really didn't want us to do it. but maybe with this we can make it happen | 18:38:20 |
| 13 Aug 2024 |
 Randy Eckenrode | In reply to @emilazy:matrix.org
anyway, I guess mixing incompatible feature sets does complicate this significantly đź« Can feature flags be included in the name? This seems like a problem the Nix approach is well-equipped to handle. | 13:55:31 |
| emily | AIUI, if you have dependencies on crate A that depends on C with feature X and crate B that depends on C with feature Y, Cargo will build crate C with features {X,Y} | 13:56:36 |
| emily | that's full version resolver territory | 13:56:46 |
| emily | we could potentially get away with just doing our own dumb Nix-like resolution and having more duplicates, but as of now there's no way to convince Cargo to let us do that | 13:57:03 |
 K900 | Correct, Cargo features are strictly additive | 13:57:18 |
| emily | with the user-wide cache thing I think we'd end up just getting a cache miss on crate C with this, which wouldn't be so bad | 13:57:36 |
| emily | actually resolving all the features would be cool, but like, the idea is to avoid reimplementing Cargo | 13:57:50 |
| emily | since people have already tried that with Nix and AIUI not been successful enough for us to adopt at a wide scale | 13:58:04 |
| emily | (though if someone is brave enough to truly try…) | 13:58:14 |
| emily | anyway we will actually have to handle features to some extent for transitive dependencies and stuff… so it's possible I'll end up needing most of this complexity anyway | 14:01:15 |
| emily | but I suspect not because stuff will just propagate | 14:01:22 |
| emily | the nice thing about treating packages as source is that the source is invariant between build configurations | 14:01:32 |
| emily | I've written about 60% of the program in my head so there's only 90% of it left to do when I actually start typing | 14:02:02 |
| Randy Eckenrode | In reply to @emilazy:matrix.org
AIUI, if you have dependencies on crate A that depends on C with feature X and crate B that depends on C with feature Y, Cargo will build crate C with features {X,Y} Oh. It doesn’t keep them separate like it does different’t versions? What if crate features are incompatible? (Don’t do that?) | 14:04:56 |
| emily | yeah, incompatible crate features are officially not supported. so of course people do them anyway, and it breaks | 14:05:30 |
| emily | it doesn't separate out different versions, or at least, it doesn't completely separate them like Node does | 14:05:40 |
| emily | AIUI for each set of "mergeable" requirements it picks the highest version compatible with all of them | 14:05:55 |
| emily | so you get duplication if you have deps on ^1 and ^2, but ^1, ^1.2 and <=1.3 will pick 1.2 for all of them | 14:06:12 |
| Randy Eckenrode | I thought cargo could use foo-0.2 and foo-0.3 if they were needed by transitive dependencies. | 14:06:33 |
| emily | in that case, we'd have crate_1, crate_2, crate_1_2 or something (the latter to satisfy the <=1.3 requirement in that one package) | 14:06:52 |
