Live data from Hacker News

Cargo: predictable dependency management

blog.rust-lang.org

51–60 of 146 posts

Re: Cargo: predictable dependency management

#51

Earlier quoted context omitted.

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.

Creating, maintaining, shepherding through distro processes, etc. All so you can then eventually build your own code.

Re: Cargo: predictable dependency management

#52

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…

> 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

Maybe the reason why it's hardly talked about is because it's common sense and pretty much all dependency managers support it?

Except node of course, because they have no idea what they're doing.

Re: Cargo: predictable dependency management

#53
post #45
post #27

Earlier quoted context omitted.

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.

Servo's efforts to upgrade their version of rustc used to be legendarily traumatic, these days it's comparatively tame. :)

Re: Cargo: predictable dependency management

#54
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

Why are the fallbacks (~/.config and ~/.cache) utter garbage?

Re: Cargo: predictable dependency management

#55
post #31

Earlier quoted context omitted.

It attempts to unify them if it can, but if they cannot be unified, it will include both versions.

Include both how? Make renamed copies to have two and modify the code to use the new names?

Rust mangles symbols with version information, so it's no trouble to have two versions of the same library in the same binary if necessary.

Re: Cargo: predictable dependency management

#56
post #53
post #45

Earlier quoted context omitted.

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

Servo's efforts to upgrade their version of rustc used to be legendarily traumatic, these days it's comparatively tame. :)

Right, and if the binary toolchains would be built with musl (not targeting musl) statically, we could have a rustc+cargo that works on both glibc and musl, avoiding two versions.

Re: Cargo: predictable dependency management

#57
post #45
post #27

Earlier quoted context omitted.

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.

It downloads a regular Rust nightly build these days. It depends on the specific nightly date (because we use compiler plugins that link to unstable rustc internals), but at least we no longer have to build our own Servo-specific snapshots.

Re: Cargo: predictable dependency management

#58
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…

It's also relevant that rust can use multiple direct/indirect dependencies of different versions, due to the way that symbols are exported.

Re: Cargo: predictable dependency management

#59
post #29

Earlier quoted context omitted.

> You can yank a version, which tells Cargo not to allow any projects to form new dependencies on that version, but the version isn't actually deleted That's how RubyGems used to work, except you could contact the support team and ask them to permanently delete your gem version if something really sensitive and irrevocable was put into it. They had to change that due to their support log getting too big: http://blog.…

Cargo's policy is that if you upload secrets, you need to change the secrets because the code can't be deleted. From the aforelinked page: > A yank does not delete any code. This feature is not intended for deleting accidentally uploaded secrets, for example. If that happens, you must reset those secrets immediately.

Even if they're given a court order to take a version down? It may be their policy, but I guarantee it will happen at some point.

Re: Cargo: predictable dependency management

#60
post #29

Earlier quoted context omitted.

Cargo's policy is that if you upload secrets, you need to change the secrets because the code can't be deleted. From the aforelinked page: > A yank does not delete any code. This feature is not intended for deleting accidentally uploaded secrets, for example. If that happens, you must reset those secrets immediately.

Even if they're given a court order to take a version down? It may be their policy, but I guarantee it will happen at some point.

We will comply with the law where required.
Post reply on HN