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

91–100 of 146 posts

Re: Cargo: predictable dependency management

#91

Post by airless_bar »

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…

Let's just see what happens when they get their first court order, which they certainly will (due to their global name-spacing).

Re: Cargo: predictable dependency management

#92

Post by dikaiosune »

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…

Rust isn't targeting all of the same use areas as the other languages you mentioned (and FWIW I've heard not great things about go dependency mgt). Many, if not most, of the rust materials in the wild are pitching it as an alternative to C and C++, because that's where the language has the clearest competitive advantage.

Re: Cargo: predictable dependency management

#93

Post by steveklabnik »

airless_bar wrote: post #91
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…

Let's just see what happens when they get their first court order, which they certainly will (due to their global name-spacing).

As I said below, we will comply with the law.

(And I'm not sure what that has to do with namespacing.)

Re: Cargo: predictable dependency management

#94

Post by conradev »

steveklabnik wrote: post #90
conradev wrote: post #86

Earlier quoted context omitted.

That's awesome to hear. Would it be possible to make an attribute like #[deny(non_deterministic)] which would error if `build.rs` or similar is present? Also, for usage of things like the `file!` macro, which might mess up determinism based on the build directory. Theoretically, syntax extensions could be written to be deterministic as well (for a given version, of course). Is there a tracking issue on this currently…

There isn't, it might be an interesting idea! Not allowing build.rs would eliminate a lot of crates, and not all build.rs' are nondeterministic... So that's tough.

Yeah. Perhaps developers could attribute functions in `build.rs` specifically with "deterministic", so you could see what in the dependency graph isn't deterministic.

Unfortunately, unlike with borrowck, reproducibility is inherently hard to verify, and you'd have to do it manually with a VM or some different build environment.

This is interesting: https://github.com/rust-lang/rust/pull/33296

Re: Cargo: predictable dependency management

#95

Post by eyko »

steveklabnik wrote: post #93
airless_bar wrote: post #91

Earlier quoted context omitted.

Let's just see what happens when they get their first court order, which they certainly will (due to their global name-spacing).

As I said below, we will comply with the law. (And I'm not sure what that has to do with namespacing.)

I believe he means that packages aren't namespaced (owner/package-name), so if I publish a package called nike, Nike could come and want to take over the package name.

Re: Cargo: predictable dependency management

#96

Post by dbaupp »

cm3 wrote: post #56
kibwen wrote: post #53

Earlier quoted context omitted.

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.

Could you explain what you're referring to? It seems like a total non sequitur, since as far as I know, there has never been any pain (or even rumour of pain) in a Rust upgrade caused by what libc the compiler uses, but rather breakage in the unstable features that servo uses.

Re: Cargo: predictable dependency management

#97

Post by themartorana »

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…

I think this is the scenario that has me feeling warm and fuzzy about vendoring. Sure, eventually even vendored dependencies will become stale, but I don't have to rely on a package manager past the initial delivery. It's not perfect, but I don't sweat code disappearing from a black box I don't own.

Re: Cargo: predictable dependency management

#98

Post by dbaupp »

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, maybe it is even better than Rust's, in which case it would be amazing.)

Re: Cargo: predictable dependency management

#99

Post by dbaupp »

shadowmint wrote: post #87

Libraries can be compiled as static libraries or dynamic libraries. even static libraries might want to do some dynamic linking (for example, against the system version of openssl). haha... I like cargo a lot, but I feel this is glossing over the biggest issue building rust code has: Building and linking to native libraries. Similarly, applications are often built for different architectures, operating systems, or ev…

> Oh? I'd love to see that compiling on a different operating system.

You'll note from the file paths in the blog post ("file:///Users/ykatz/...") that the builds are actually being run on a OSX machine: winapi is careful to not break builds when it is irrelevant.

It is possible and even necessary to write code that depends on operating system details (e.g. to implement the high-level cross-platform code), and indeed that code may not compile on different platforms. The point is that rustc and cargo together provide the tools to make it possible and easy to write code that builds and runs everywhere everywhere, they don't/can't/shouldn't guarantee it.

Re: Cargo: predictable dependency management

#100

Post by kibwen »

eyko wrote: post #95
steveklabnik wrote: post #93

Earlier quoted context omitted.

As I said below, we will comply with the law. (And I'm not sure what that has to do with namespacing.)

I believe he means that packages aren't namespaced (owner/package-name), so if I publish a package called nike, Nike could come and want to take over the package name.

Global namespacing has nothing to do with that. Even with per-user namespacing, there's nothing to stop a user from making their username "nike" and publishing all their code under "nike/package-name", which would be subject to just as much potential legal action as a package named "nike" itself. Likewise there's also nothing to stop Bob from uploading "bob/nike".
Post reply on HN