Live data from Hacker News

Cargo: predictable dependency management

blog.rust-lang.org

11–20 of 146 posts

Re: Cargo: predictable dependency management

#11
post #4

Cargo assumes you want to cache downloaded/built dependencies at the granularity of a unix user account. It's very easy to break things if you try to force current cargo cache dependencies at the per-project level and there's been no interest in caching things at a per-machine or shared-between-machines level. If duplicating compilation work is desirable to ensure some amount of noninterference, it should be supporte…

> it should put things in $XDG_CONFIG_HOME and $XDG_CACHE_HOME

I was going to submit an issue but one already exists [1][2]

[1] https://github.com/rust-lang/cargo/pull/148

[2] https://github.com/rust-lang/cargo/issues/1734

Re: Cargo: predictable dependency management

#12
post #7

How does Cargo handle indirect dependency visibility? This article talks about visibility in terms of "do I need to manually include indirect dependencies? No!" but not in terms of "can I accidentally write code against an indirect dependency?" which isn't sufficiently answered. If the answer is that indirect dependencies are still visible, I'd be interested in knowing if rust-lang/cargo plan to change that, similar…

Short answer: `extern crate foo;` doesn’t work if `foo` is an indirect dependency. So you cannot accidentally use something without declaring it in `Cargo.toml`. Longer answer: when running rustc, Cargo passes individual `--extern bar=/path/to/bar.rlib` options for each direct dependency, not just a path to a directory with everything. You can see the exact command with `cargo build --verbose` or `cargo build -v`.

[deleted]

Re: Cargo: predictable dependency management

#13

I like many things about Rust, but Cargo alone is what initially got me started with it. I was in the process of setting up a fresh C++ project with vendored dependencies, and it was just an absolute nightmare. In contrast, it took me about 5 minutes to get a Rust project set up with comparable dependency complexity.

Speaking of which, is there any good package management system for modern C/C++?

Conan seems to have appeared recently but I haven't yet tried it myself. https://www.conan.io/

Re: Cargo: predictable dependency management

#14

Earlier quoted context omitted.

Speaking of which, is there any good package management system for modern C/C++?

I've had biicode recommended to me ( https://github.com/biicode/biicode ), but I haven't tried it yet. EDIT: Also worth noting that a common response I've heard to "I need a better manager for my dependencies" is "you have a system package manager for a reason."

What do they say when you reply "Windows"?

Re: Cargo: predictable dependency management

#15
post #14

Earlier quoted context omitted.

I've had biicode recommended to me ( https://github.com/biicode/biicode ), but I haven't tried it yet. EDIT: Also worth noting that a common response I've heard to "I need a better manager for my dependencies" is "you have a system package manager for a reason."

What do they say when you reply "Windows"?

I think it goes without saying that those with that sort of response tend not to use Windows, and also often seem to assume that a perfectly in-order Linux/Unix install is the only way to build software.

Re: Cargo: predictable dependency management

#16
post #4

Cargo assumes you want to cache downloaded/built dependencies at the granularity of a unix user account. It's very easy to break things if you try to force current cargo cache dependencies at the per-project level and there's been no interest in caching things at a per-machine or shared-between-machines level. If duplicating compilation work is desirable to ensure some amount of noninterference, it should be supporte…

You could also change $CARGO_HOME per project, to get a per-project cache.

Re: Cargo: predictable dependency management

#17

I like many things about Rust, but Cargo alone is what initially got me started with it. I was in the process of setting up a fresh C++ project with vendored dependencies, and it was just an absolute nightmare. In contrast, it took me about 5 minutes to get a Rust project set up with comparable dependency complexity.

Speaking of which, is there any good package management system for modern C/C++?

The Meson build system http://mesonbuild.com/ seems to have a package manager like dependency management system.

Re: Cargo: predictable dependency management

#18
post #7

How does Cargo handle indirect dependency visibility? This article talks about visibility in terms of "do I need to manually include indirect dependencies? No!" but not in terms of "can I accidentally write code against an indirect dependency?" which isn't sufficiently answered. If the answer is that indirect dependencies are still visible, I'd be interested in knowing if rust-lang/cargo plan to change that, similar…

As the sibling answer says, they are not visible.

However, crates can re-export symbols they have imported from their dependency, which couples their semver to that dependency's in a way that people have often not realized. This has been the source of some upgrade headaches so far, but its less of a problem than it has been with languages in my experience.

Re: Cargo: predictable dependency management

#19

I like many things about Rust, but Cargo alone is what initially got me started with it. I was in the process of setting up a fresh C++ project with vendored dependencies, and it was just an absolute nightmare. In contrast, it took me about 5 minutes to get a Rust project set up with comparable dependency complexity.

Speaking of which, is there any good package management system for modern C/C++?

Conan is the most promising one, they just released a new version:

http://blog.conan.io/2016/05/03/New-conan-release-0-9.html

Arne Mertz has a Vagrant box for people who want to experiment with a "4C" development environment (Clang, Cmake, Conan, Clion).

https://github.com/arnemertz/Xubuntu1604_DevBox

Re: Cargo: predictable dependency management

#20
post #4

Cargo assumes you want to cache downloaded/built dependencies at the granularity of a unix user account. It's very easy to break things if you try to force current cargo cache dependencies at the per-project level and there's been no interest in caching things at a per-machine or shared-between-machines level. If duplicating compilation work is desirable to ensure some amount of noninterference, it should be supporte…

> it should put things in $XDG_CONFIG_HOME and $XDG_CACHE_HOME

My unix does not follow XDG[0], neither of these are set and the XDG "fallbacks" are utter garbage, now what?

[0] hell, only a minority of linux distros do at all

Post reply on HN