Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cargo: predictable dependency management

blog.rust-lang.org

Post reply on HN
Print view View original

71–80 of 146 posts

Re: Cargo: predictable dependency management

#71

Post by tatterdemalion »

qznc wrote: post #34
dikaiosune wrote: post #2

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.

I understand that old languages like C++ or Java have problems providing a single package manager. It seems that newer languages have roughly equivalent services. Are there any big differences between Cargo and Python/Go/D/Ruby/Javascript/etc?

I find cargo easier to use than bundler or npm. Specifically I never deal with "environment hell" where some config hasn't been picked up and I'm pulling in the wrong version of a dependency or the language or whatever. This is partly because of the way cargo is designed, but its also helped a lot by the fact that Rust generates statically linked binaries in one build instead of being a continuous interpreter process.

Re: Cargo: predictable dependency management

#72

Post by bulkan »

incepted wrote: post #52
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…

> 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.

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

NPM and node are two different things.

Re: Cargo: predictable dependency management

#73

Post by [deleted] »

waffle_ss wrote: post #59
eridius wrote: 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.

[deleted]

Re: Cargo: predictable dependency management

#74

Post by dkersten »

waffle_ss wrote: post #59
eridius wrote: 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.

Court orders will be a lot less frequent than normal user requests so the overhead to the team won't be as high.

Re: Cargo: predictable dependency management

#75

Post by cfallin »

eridius wrote: post #29
waffle_ss wrote: post #23

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.

This seems a bit... inflexible. I definitely understand the arguments for not breaking builds and for reducing administrative overhead and such, but not every bit of secret data can be revoked like a key/credential can. What if you accidentally include user data, or proprietary business-logic code, or...? (Yes, with proper data hygiene and processes you'd never even come close to doing any of that, but it seems there should still be an escape hatch.)

Re: Cargo: predictable dependency management

#76

Post by thristian »

masklinn wrote: post #20
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…

> 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

How can a unix follow or not follow XDG? It's an application level concern, not a distro or kernel level one.

Re: Cargo: predictable dependency management

#77

Post by steveklabnik »

thristian wrote: post #76
masklinn wrote: post #20

Earlier quoted context omitted.

> 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

How can a unix follow or not follow XDG? It's an application level concern, not a distro or kernel level one.

Distros distribute application packages. If those packages follow XDG or not, I would say the distro does or doesn't.

Re: Cargo: predictable dependency management

#78

Post by eridius »

kibwen wrote: post #50
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 Carg…

Ah, good to know. I assumed the index was hosted as part of crates.io but I didn't actually bother to check. The point I was trying to make (even if I didn't communicate it properly) was that if crates.io goes away for good, the index will too and so it won't really matter that the code is inaccessible because cargo won't know where to find it anyway. Of course, based on what you said, it's certainly possible for everyone involved in crates.io to get hit by a bus and crates.io vanish when the S3 bill goes unpaid while still leaving the index up on GitHub, but if crates.io is taken down intentionally then presumably so will the index.

Re: Cargo: predictable dependency management

#79

Post by eridius »

incepted wrote: post #52
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…

> 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.

Except not all dependency managers support it. I'm not even sure if it's safe to say that a majority of dependency managers support it.

Re: Cargo: predictable dependency management

#80

Post by waffle_ss »

dkersten wrote: post #74
waffle_ss wrote: post #59

Earlier quoted context omitted.

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.

Court orders will be a lot less frequent than normal user requests so the overhead to the team won't be as high.

Of course, and I totally agree with their approach. I'm just saying the narrative eridius is pushing that somehow they can make assurances about things never being deleted totally false. For example, I'm sure if someone somehow put child pornography in a Rust crate it would rightly be taken down pretty fast (and not require a court order).

Also I just wanted to give a little history because eridius's original comment made it sound like it was a novel concept.

Post reply on HN