3 ms·

> If we're talking build system, nobody is forcing you to use Crates.io with cargo, they just make it easy to. Using cargo with distributed dependencies (e.g.:

> If we're talking build system, nobody is forcing you to use Crates.io with cargo, they just make it easy to. Using cargo with distributed dependencies (e.g.: using git repositories) has several missing features, like resolving the latest semver-compatible version, etc. No only is it _easier_ to use cargo with crates.io, it's harder to use with anything else because of missing or incomplete features. > You can use path-based dependencies just like CMake/VCPkg,Conan, or you can DIY the library. Have you tried to do this? Cargo is a "many things in one" kind of tool, compiling a Rust library (e.g.: dependency) without it is a pain. If cargo had instead been multiple programs that each on one thing, it might be easier to opt out of it for regular projects.

jvanderbot 2y ago
Compared to ... cmake? vckpg? conan? I have never had a good experience with those. However, using mydep.path = <path> in cargo has never been an issue. And I hate to say it, path-based deps are much easier in C++ / C than other "make the build system do a coherent checkout" options like those mentioned above. So we're at worst parity for this use case, IMHO and subject to my own subjectivity, of course
- TeMPOraL 2y ago
  Speaking of Conan. Something I don't see anyone talking about is, with such systems you have not one but at least two dependencies to audit per any library you want to include. One is the library itself, but the other one is the recipe for the package manager. At least with Conan, the recipes are usually written by third parties that are not affiliated with the dependency they're packaging. Now, Conan recipes are usually full-blown Python scripts that not only decide where to pull the target sources from themselves, they also tend to ship patches, which they apply to the target source code before building. That is, even if package source is specified directly and fixed on specific release, you still can't assume you're actually building the exact source of that release, because the recipe itself modifies the code of the release it pulled. IMHO, trying to do OSS clearance on dependencies pulled via Conan makes very little sense if you don't also treat each Conan recipe as a separate library. But no one does.
croemer 2y ago
Why would you want to automatically resolve the latest semver compatible version from git if you care about security? That's worse than cargo.io where tags are stable, whereas git allows tags to be edited. > No only is it _easier_ to use cargo with crates.io, it's harder to use with anything else because of missing or incomplete features. You're saying the same thing twice here: yes it's easier to use cargo with crates.io. It follows immediately that it's harder to use without crates.io. That doesn't make your argument stronger. Here's an article on how to use cargo without crates: https://thomask.sdf.org/blog/2023/11/14/rust-without-crates-io.html https://thomask.sdf.org/blog/2023/11/14/rust-without-crates-...

jvanderbot 2y ago

Compared to ... cmake? vckpg? conan? I have never had a good experience with those. However, using mydep.path = <path> in cargo has never been an issue. And I hate to say it, path-based deps are much easier in C++ / C than other "make the build system do a coherent checkout" options like those mentioned above. So we're at worst parity for this use case, IMHO and subject to my own subjectivity, of course

TeMPOraL 2y ago
Speaking of Conan. Something I don't see anyone talking about is, with such systems you have not one but at least two dependencies to audit per any library you want to include. One is the library itself, but the other one is the recipe for the package manager. At least with Conan, the recipes are usually written by third parties that are not affiliated with the dependency they're packaging. Now, Conan recipes are usually full-blown Python scripts that not only decide where to pull the target sources from themselves, they also tend to ship patches, which they apply to the target source code before building. That is, even if package source is specified directly and fixed on specific release, you still can't assume you're actually building the exact source of that release, because the recipe itself modifies the code of the release it pulled. IMHO, trying to do OSS clearance on dependencies pulled via Conan makes very little sense if you don't also treat each Conan recipe as a separate library. But no one does.

croemer 2y ago

Why would you want to automatically resolve the latest semver compatible version from git if you care about security? That's worse than cargo.io where tags are stable, whereas git allows tags to be edited. > No only is it _easier_ to use cargo with crates.io, it's harder to use with anything else because of missing or incomplete features. You're saying the same thing twice here: yes it's easier to use cargo with crates.io. It follows immediately that it's harder to use without crates.io. That doesn't make your argument stronger. Here's an article on how to use cargo without crates: https://thomask.sdf.org/blog/2023/11/14/rust-without-crates-io.html https://thomask.sdf.org/blog/2023/11/14/rust-without-crates-...