| 13 Aug 2024 |
 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 |
| emily | extra stuff would get propagated into the vendor directory and then just not used | 14:06:56 |
| emily | In reply to @reckenrode:matrix.org
I thought cargo could use foo-0.2 and foo-0.3 if they were needed by transitive dependencies. yes | 14:07:00 |
| emily | 0.2 and 0.3 are major versions though | 14:07:05 |
| emily | ^0.2 and ^0.3 are incompatible, but ^1 and <=1.3 aren't | 14:07:22 |
| emily | so even if 1.5 exists, it will pick 1.2 for both latter requirements because of global version resolution | 14:07:31 |
