| 13 Aug 2024 |
 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 |
| emily | (again AIUI, I don't know the exact details) | 14:07:36 |
| emily | so with ^1, <=1.3, ^1.4, ^2 all in the dependency tree, it'd pick 1.3, 1.5, 2.99 | 14:08:11 |
| emily | (and my current idea of what we should do for Nixpkgs would mean we'd have packages dep_1 (1.5), dep_1_3 (packaged because something wants <=1.3), dep_2 (2.99), end up propagating them all into the vendor directory and it'd just work) | 14:10:37 |
| emily | thinking it'd look something like pkgs/rust-crates/dep/{{1,1.3,2}.json,overrides.nix}, where the latter would be hand-written and specify things like non-Rust dependencies, environment variables, perhaps features we want to inject, etc. | 14:11:37 |
| emily | (considered pkgs/by-name but don't think it'd work for this. an end-user would never want to consume one of these anyway; we'll instead have e.g. pkgs/by-name/ri/ripgrep/package.nix doing something like { rustPackages }: rustPackages.toRustApplication rustPackages.crates.ripgrep_latest) | 14:12:20 |
| emily | P.S. send your best cargo shipping software pun names directly to my address | 14:13:26 |
 benjamin | is there a way to select specific targets with fromManifestFile in fenix? | 18:51:17 |
| benjamin | (I'm trying to refactor a package that was previously using fromToolchainFile to avoid IFD) | 18:51:30 |
 linj | hmm, how can I find all packages using rustPlatform, either buildRustPackage or various hooks? I made some changes to those rust hooks and want to check if I break some packages. | 19:04:19 |
