Cargo: predictable dependency management • Hacker News Board

Re: Cargo: predictable dependency management

#41

Post by steveklabnik » Thu, May 05, 2016, 9:11 PM UTC

cm3 wrote: post #38

steveklabnik wrote: post #37

Earlier quoted context omitted.

It doesn't have to do any renaming or modifying of names. Rust has a module system, so each dependency will use the version they need. The only time it doesn't Just Work is if one of those crates re-exports a type from the sub-crate in a public manner, and then you try to call something from the other crate with a value of that type. You'll get a compile-time error about mismatched types.

But it sounds like that's what's going on. Using foo-1.1 in bar.rs and foo-2.2 in rabbit.rs.

Sure. That will Just Work in every case _except_ if bar and rabbit both re-export a type from foo, and you try to use them together. If they don't re-export anything, then it all works just fine. No renaming or transformations needed.

Re: Cargo: predictable dependency management

#42

Post by xkarga00 » Thu, May 05, 2016, 9:12 PM UTC

I have been working as a Go programmer for the past two years and I really love the language but dependency management has been one of the biggest pains for me. Godep really sucks (that's what we use in my current gig - we plan on switching to Glide, still haven't played around with it) and I am not sure I like the fact that I need to go out in the wild and choose between the rest of the existing solutions. I would prefer to have something that works ootb. The Rust team really got this right and Cargo is amazing. One of the main reason I have been dabbling with Rust lately.

Re: Cargo: predictable dependency management

#43

Post by dbaupp » Thu, May 05, 2016, 9:14 PM UTC

gue5t wrote: 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…

> Cargo assumes you want to cache ... built dependencies at the granularity of a unix user account

This isn't true: actual build artifacts are cached in a per-project way (in `./target` by default). Cargo does download all packages to a user-shared directory, but this directory is essentially immutable, just a list of the source code.

Sharing more broadly than per-project is the form that is unreliable, things can change subtly between projects e.g. different targets, different compiler flags. Of course, cargo has essentially full information about everything involved in a build and so can track this---in the limit caching all the different configurations of each crate version---but I don't think it does currently (I recall an issue about it, but I cannot find it at the moment).

Re: Cargo: predictable dependency management

#44

Post by cm3 » Thu, May 05, 2016, 9:15 PM UTC

It's great that Raph's line-breaking code has been reused, but in contrast to Mozilla projects any contribution to it will now require assigning copyright to Google (like Ubuntu or Microsoft's CLA require as well). At least it's a tiny piece, so may not hurt too much in terms of prevented contributions.

Re: Cargo: predictable dependency management

#45

Post by cm3 » Thu, May 05, 2016, 9:16 PM UTC

Gankro wrote: post #27

SimonSapin wrote: post #3

It was a happy day when Servo ditched a big hairy pile of makefiles + git submodules and switched to Cargo :)

Happier than Rust 1.0 and the end of The Rustup?

End of The Rustup? AFAICS, it's still downloading a very specific servo-only rustc.

Re: Cargo: predictable dependency management

#46

Post by cm3 » Thu, May 05, 2016, 9:18 PM UTC

dikaiosune wrote: post #9

gue5t wrote: 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…

There's an ongoing discussion of using build caches with Cargo: https://internals.rust-lang.org/t/is-a-shared-build-cache-a-... TLDR: There's interest, but some wrinkles need to be sorted out.

I like Nix-style caches myself, but a gc-cache command is needed in order to clean up only the stuff that isn't referenced anymore. I hope that's a design consideration.

Re: Cargo: predictable dependency management

#47

Post by FreeFull » Thu, May 05, 2016, 9:22 PM UTC

dikaiosune wrote: post #15

McP wrote: post #14

Earlier quoted context omitted.

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.

And also that you're fine with creating a package for any dependency that doesn't have one.

Re: Cargo: predictable dependency management

#48

Post by conradev » Thu, May 05, 2016, 9:22 PM UTC

I appreciate that predictability is a big priority with Cargo.

I feel like Rust and Cargo are in a great position to deterministically (per compiler version, per set of build flags) build libraries. That would be an amazing step forward in security if it could be enforced. Does anyone know if this is planned?

https://reproducible-builds.org

Re: Cargo: predictable dependency management

#49

Post by steveklabnik » Thu, May 05, 2016, 9:26 PM UTC

conradev wrote: post #48

I appreciate that predictability is a big priority with Cargo. I feel like Rust and Cargo are in a great position to deterministically (per compiler version, per set of build flags) build libraries. That would be an amazing step forward in security if it could be enforced. Does anyone know if this is planned? https://reproducible-builds.org

In general, we are very interested in reproducible builds, and have fixed bugs where accidental non-determinism has crept in. However, it can be easy to reintroduce with build.rs, which allows for executing arbitrary Rust code before a build. Syntax extensions are another problem here. But the scope is much reduced, it's true.

Re: Cargo: predictable dependency management

#50

Post by kibwen » Thu, May 05, 2016, 9:30 PM UTC

lilyball wrote: post #21

Something that I'm surprised this page doesn't talk about, and which is very important considering the recent hubbub over left-pad, is that any dependency you get on Cargo can be relied upon to continue to exist forever (well, as long as the crates.io site still exists, but if that goes away so does the Cargo index). The reason is because you can't ever remove a published version of your crate from crates.io. You can…

  > if that goes away so does the Cargo index

Not so, the location of the index is independent of crates.io. Currently the index itself is just hosted on Github, whereas all of crates.io is hosted on S3. Which is actually kind of a pain sometimes, since if Github goes down it means that Cargo won't be able to find the index and I don't know if there's an easy way to override the index check. In the future I expect Cargo will gracefully continue if the index can't be updated due to connection failure, though I'd think it would prompt the user to make sure they're aware that their local copy of the index might be out of date.