Cargo: predictable dependency management • Hacker News Board

Re: Cargo: predictable dependency management

#101

Post by wyldfire » Fri, May 06, 2016, 2:26 AM UTC

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.

It wouldn't likely meet the standard of "confusingly similar" unless you called it "Nike" in order to somehow leverage the actual shoe brand (logos 'n all). But even if it didn't, you could imagine an index operator succumbing to the (unreasonable) request of a lawyer in order to avoid a conflict requiring representation.

Re: Cargo: predictable dependency management

#102

Post by fungos » Fri, May 06, 2016, 2:30 AM UTC

akhilcacharya wrote: post #5

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.

Speaking of which, is there any good package management system for modern C/C++?

Even if it doesn't has too much support, I highly recommend fips: https://github.com/floooh/fips

I have been using it, adding some libs and even contributing some changes. You should really give it a try!

Re: Cargo: predictable dependency management

#103

Post by yazaddaruvala » Fri, May 06, 2016, 3:40 AM UTC

My Cargo wish list!

1. Like every enterprise build system I've ever gotten to use, I wish Cargo would manage the compiler version as well.

2. The compiler forces me to mark `unsafe` functions/blocks to use unsafe code. Why does Cargo not force me to mark `unsafe` dependencies to use unsafe code?[0]

[0] Only dependencies that explicitly use `unsafe` should need to be marked in my Cargo.toml. eg. Iron doesn't use `unsafe`, but Mio does. Iron depends on Hyper depends on Mio. If I have a dependence on Iron, I really want to be able to mark `#[unsafe_deep_dep] mio`, or else my build fails.

Re: Cargo: predictable dependency management

#104

Post by mavelikara » Fri, May 06, 2016, 3:46 AM UTC

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?

Java has Maven Repository. This can be use from within Ant (Ivy), Maven, Gradle, sbt etc.

Both Ruby and Python are almost as old, if not older than Java. JavaScript is only slightly younger.

Re: Cargo: predictable dependency management

#105

Post by cetra3 » Fri, May 06, 2016, 3:50 AM UTC

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?

Re: Cargo: predictable dependency management

#106

Post by steveklabnik » Fri, May 06, 2016, 4:00 AM UTC

yazaddaruvala wrote: post #103

My Cargo wish list! 1. Like every enterprise build system I've ever gotten to use, I wish Cargo would manage the compiler version as well. 2. The compiler forces me to mark `unsafe` functions/blocks to use unsafe code. Why does Cargo not force me to mark `unsafe` dependencies to use unsafe code?[0] [0] Only dependencies that explicitly use `unsafe` should need to be marked in my Cargo.toml. eg. Iron doesn't use `unsa…

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.

Re: Cargo: predictable dependency management

#107

Post by steveklabnik » Fri, May 06, 2016, 4:01 AM UTC

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?

Servo relies on a specific version of Rust, and Mach helps with that.

Cargo isn't a general build system, it builds Rust code. I use Make to drive Cargo for my OS project, because I use nasm to build the asm and Cargo to build the Rust, for example.

Re: Cargo: predictable dependency management

#108

Post by riffraff » Fri, May 06, 2016, 4:52 AM UTC

tatterdemalion wrote: post #70

incepted wrote: post #52

Earlier quoted context omitted.

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

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 breaking legal or ethical laws)

It can be argued that users must not do that or that cargo.io doesn't have to oblige, but if they, for example, get a DMCA notice they'll still have to.

Re: Cargo: predictable dependency management

#109

Post by yazaddaruvala » Fri, May 06, 2016, 4:54 AM UTC

steveklabnik wrote: post #106

yazaddaruvala wrote: post #103

My Cargo wish list! 1. Like every enterprise build system I've ever gotten to use, I wish Cargo would manage the compiler version as well. 2. The compiler forces me to mark `unsafe` functions/blocks to use unsafe code. Why does Cargo not force me to mark `unsafe` dependencies to use unsafe code?[0] [0] Only dependencies that explicitly use `unsafe` should need to be marked in my Cargo.toml. eg. Iron doesn't use `unsa…

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 trust it, and whitelist Hyper. My build passes, I know only `std` and Hyper use `unsafe`.

Why is this helpful?

Hasn't happened yet but @reem, being human, adds an `unsafe`[0] and lets Iron's README go out of date. It happens. However, as a user, I don't like to trust documentation, and I don't like to trust other developers[1]. When I update to this version of Iron, I'd rather my builds now failed. Then I can decide if this escalation of responsibility is appropriate.

This is especially true in an enterprise context where teams of new hires do whatever it takes to push features, and "accidentally" push some really unsafe code to a deep dependency[2].

[0] Lets pretend this `unsafe` was actually used in production code: https://github.com/iron/iron/commit/ba4d197030067d4347134c2e...

[1] Hence my other preferences for type checking, core reviews, and tests.

[2] Not everything is manually catchable in code reviews. Sometimes its 3am. Sometimes whoever it was, was really new and the CR is 14 pages long and needs to be deployed Thursday! Sometimes a reviewer is just having an off-day. It happens.

Re: Cargo: predictable dependency management

#110

Post by gnoway » Fri, May 06, 2016, 4:57 AM UTC

eridius wrote: post #79

incepted wrote: post #52

Earlier quoted context omitted.

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

Package persistence is not really a dependency manager feature though, it's a package repository feature. npm didn't fail; npmjs.com did.

I'm just waiting for this to happen to bower next. AFAIK they're just a registry pointing to github. All it's going to take is someone doing a force push without thinking and we're in this same situation again.