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

111–120 of 146 posts

Re: Cargo: predictable dependency management

#111

Post by riffraff »

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?

notice that some of the really old ones (perl, tex) have had package managers for a really, really long time.

I think linux (*nix?) vs non-linux heritage might have something to do with it.

Re: Cargo: predictable dependency management

#112

Post by f2f »

dbaupp wrote: post #98
dschiptsov wrote: post #88

So, dependencies in, say, cabal or go or CL are unpredictable? The trend to put meaningless but catchy adjectives, like "safe" and "predictable", as if everything else is opposite, is misleading. Designers of classic languages were not some arrogant punks (they were brilliant, like David Moon and other guys of his generation), and the most of findamental problems were well understood in times of Standard ML or Common…

By all reports ("cabal hell"), Cabal is unpredictable, and Go's dependency management problems prompted countless external tools until the recent vendoring work: with the default `go get`, there is no guarantee that a build will be the same from day to day, as the best one can do is point at a given branch of a repository (a moving target), not tags or commits. (I have no idea on CL's dependency management situation,…

minor factual adjustment: "go get" doesn't update a package once it's been downloaded. you need to force it.

"there is no guarantee that a build will be the same from day to day" is simply not true.

Re: Cargo: predictable dependency management

#113

Post by gnoway »

riffraff wrote: post #108
tatterdemalion wrote: post #70

Earlier quoted context omitted.

This is incorrect and very rude. Rubygems has also implemented an automated delete feature. Rubygems and NPM have orders of magnitude more users than crates.io; once crates.io approaches that scale the team will have to allow users to delete crates or somehow find funding to field these kinds of support tickets.

the parent comment might have been worded better, but it has a point, i.e. removing published code generally has to be supported in some way to handle special situations, e.g. * people publish stuff inadvertently (i.e. private information/keys) * people publish stuff they are not allowed to (i.e. copyright and trademark violations) * people publish stuff you do not want to see published (i.e. stuff related to breakin…

I think the key is that crates.io (and rubygems.org, nuget.org, etc.) as repo owners have to own the removal operation themselves and not delegate that to the package owner/maintainer. The repo owner is better positioned to take package consumers' needs into account and make good decisions about when and how to remove a package.

As far as satisfying support requests: obviously exceptional stuff like DMCA gets handled, but package owners publishing keys, etc. is still their responsibility and shouldn't accelerate or even guarantee removal IMO. If you publish secrets, it's not crates.io's responsibility to help you hide that mistake, and you need to be changing those secrets anyway.

Re: Cargo: predictable dependency management

#114

Post by yazaddaruvala »

yazaddaruvala wrote: post #109
steveklabnik wrote: post #106

Earlier quoted context omitted.

At the fundamental level, the machine is unsafe. This means that if unsafe were transitive, all code would need to be marked unsafe. Use a String? Your crate needs to be marked unsafe.

We agree. I think there was a bit of misunderstanding. I don't think transitive unsafe is appropriate. Only crates which use `unsafe` explicitly should need to be whitelisted. Fun Example: I need to depend on Iron. Iron boasts in its README that it doesn't use `unsafe`. Cool. However, Iron depends on Hyper. Hyper is complicated, it needs to use `unsafe`, I can understand that. Hyper is also used by a lot of people, I…

Another really cool thing is:

Even slightly discouraging the use of unsafe via Cargo will push crate owners to find already trusted "miro-crates" which abstract their usage of unsafe. Imagine something akin to left-pad existed solely to abstract unsafe. Most crates already use it, so most teams already whitelist it. Using finding and using a micro-crate might mean less friction for users to add your dependency into their application.

Benefits:

1. Smaller the crate, smaller the surface area, better the audit-ability.

2. The more people using the same crate, the less probable there is a bug.

3. If a relatively small crate exists, solely for its abstraction of `unsafe`, and it is relatively popular, then that could be a good indicator for moving that logic into `std`.

Re: Cargo: predictable dependency management

#115

Post by dbaupp »

f2f wrote: post #112
dbaupp wrote: post #98

Earlier quoted context omitted.

By all reports ("cabal hell"), Cabal is unpredictable, and Go's dependency management problems prompted countless external tools until the recent vendoring work: with the default `go get`, there is no guarantee that a build will be the same from day to day, as the best one can do is point at a given branch of a repository (a moving target), not tags or commits. (I have no idea on CL's dependency management situation,…

minor factual adjustment: "go get" doesn't update a package once it's been downloaded. you need to force it. "there is no guarantee that a build will be the same from day to day" is simply not true.

Oh, indeed. I must've got mixed up: it doesn't guarantee that builds will the same from machine to machine (unless you run go get at the exact same instant).

Re: Cargo: predictable dependency management

#116

Post by SimonSapin »

steveklabnik wrote: post #16
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…

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

Servo does this by default. (People who tried Servo but don’t otherwise develop in Rust didn’t like having random files in their home directory.)

Re: Cargo: predictable dependency management

#117

Post by dschiptsov »

dbaupp wrote: post #115
f2f wrote: post #112

Earlier quoted context omitted.

minor factual adjustment: "go get" doesn't update a package once it's been downloaded. you need to force it. "there is no guarantee that a build will be the same from day to day" is simply not true.

Oh, indeed. I must've got mixed up: it doesn't guarantee that builds will the same from machine to machine (unless you run go get at the exact same instant).

So, in Golang there is no concept of package version?

For them different location (to import from) for an incompatible version is good-enough.

Re: Cargo: predictable dependency management

#118

Post by SimonSapin »

cetra3 wrote: post #105

This article purports that Servo relies solely on Cargo for the build step. If you look at the build step from github it looks like it's relying on mach also: https://github.com/servo/servo#building Shouldn't it instead be using cargo purely?

Mach is what you interact with when doing stuff in Servo, but all the build-* sub-commands end up calling Cargo, which is what does the heavy lifting.

The typical `./mach build` command will download known-good versions of Rust Nightly and Cargo (unless that’s already done), call `cargo build` with some flags, then show a system notification when it’s done. That’s it.

Re: Cargo: predictable dependency management

#120

Post by Perseids »

Something which is missing entirely in this concept (or, hopefully, only in the blog entry), are security updates. For example, let's assume I use an HTTP library whose TLS dependency has an error where it doesn't properly match the domain name in the certificate to the hostname of the server I'm connecting to. My Cargo.lock file references a TLS library of version 1.7.1, but the security patch is applied on 1.7.6 which has some breaking changes. Thus, the security update cannot happen silently (which would violate the predictability property of cargo anyway). Instead, we need a command to selectively update only packages with security updates and respectively we need a way to mark version bumps as security critical.
Post reply on HN