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

121–130 of 146 posts

Re: Cargo: predictable dependency management

#121

Post by technomancy »

gnoway wrote: post #113
riffraff wrote: post #108

Earlier quoted context omitted.

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…

> If you publish secrets, it's not crates.io's responsibility to help you hide that mistake

If you publish secrets, you're causing crates.io to perform copyright violations. It's not just about helping you hide the mistake, but about helping to stop further violations.

You shouldn't need to resort to a formal DMCA request to stop copyright violations.

Re: Cargo: predictable dependency management

#122

Post by eyko »

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…

As far as I can tell, the article isn't claiming that cross compilation in rust is easy, and it's definitely not saying that you can easily dynamically link and cross compile simultaneously. I develop on OSX but deploy to Linux, and that has always been an issue for me in Rust, compared to Go for example. The easiest approach for me so far has been building on the target platform with vagrant/virtualbox and calling it a day.

Re: Cargo: predictable dependency management

#123

Post by gnoway »

technomancy wrote: post #121
gnoway wrote: post #113

Earlier quoted context omitted.

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…

> If you publish secrets, it's not crates.io's responsibility to help you hide that mistake If you publish secrets, you're causing crates.io to perform copyright violations. It's not just about helping you hide the mistake, but about helping to stop further violations. You shouldn't need to resort to a formal DMCA request to stop copyright violations.

How is publishing a secret (I mean passwords, ssh keys, etc.) a copyright violation?

Re: Cargo: predictable dependency management

#124

Post by cm3 »

dbaupp wrote: post #96
cm3 wrote: post #56

Earlier quoted context omitted.

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.

If the official rust+cargo was built statically with musl, then a single download would work on glibc and musl distros. Right now, we don't have a download that works on musl, and one has to bootstrap on a glibc system, targeting musl, which makes it impossible to bootstrap rust+cargo on a musl distro without glibc because bootstrapping requires a snapshot.

Re: Cargo: predictable dependency management

#125

Post by riffraff »

gnoway wrote: post #113
riffraff wrote: post #108

Earlier quoted context omitted.

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…

the problem with saying "users should not publish their ssh keys" is that they will still do it and ping you with requests to remove them even if you have said it's not possible to do it, causing unnecessary support work.

That is, AFAIU, the reason the rubygems.org maintainers allow it now.

http://blog.rubygems.org/2015/04/13/permadelete-on-yank.html

Re: Cargo: predictable dependency management

#126

Post by curun1r »

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…

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

With rustup.rs becoming official, it's a much better way to handle compiler versions since it handles cargo versions as well and allows the two to be coupled together. This allows for tighter integration between cargo and rustc as well as making testing of new versions of cargo significantly easier (i.e. there's no permutation matrix of whether cargo A.B.C works flawlessly with rustc X.Y.Z)

Re: Cargo: predictable dependency management

#127

Post by gnoway »

riffraff wrote: post #125
gnoway wrote: post #113

Earlier quoted context omitted.

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…

the problem with saying "users should not publish their ssh keys" is that they will still do it and ping you with requests to remove them even if you have said it's not possible to do it, causing unnecessary support work. That is, AFAIU, the reason the rubygems.org maintainers allow it now. http://blog.rubygems.org/2015/04/13/permadelete-on-yank.html

Except they even state:

"If you’ve pushed a gem with internal code, you still need to reset API keys, URLs, or anything else sensitive despite the new behavior."

And:

"...we’ve been using an Amazon S3 bucket to store the gems for years now with versioning on - so if someone does remove gems that are necessary, we can easily restore them."

So what they've really done is given developers the illusion that the unwanted gem has been removed, while introducing the ability to break everyone's workflow just like npmjs. In some ways this is worse than before; devs still need to change secrets, and if it's non-secret sensitive code they are concerned about, it's still 'out there' and the dev still has to trust that the rubygems.org people don't do something unwanted with it.

Re: Cargo: predictable dependency management

#128

Post by weinzierl »

steveklabnik wrote: post #62
weinzierl wrote: post #61

Earlier quoted context omitted.

> well, as long as the crates.io site still exists, but if that goes away so does the Cargo index That makes me wonder: Is it easy or possible to replace crates.io with a self hosted repository? Background of the question is that I know of a company where access to the standard public maven repo is forbidden. They use a commercial repository provider but I don't know if it is hosted on premises.

It's not easy, but it's possible. Everything is open source, and Cargo can easily be pointed at whatever host you want. The feature that I'd like to see but haven't found the time to implement is delegation: "look at this index first, but if it's not here, go look at this other one". Right now, if you spin up your own crates.io and point Cargo at it, it won't have any packages... which works for some people, but not…

> "look at this index first, but if it's not here, go look at this other one"

I agree that this would be very helpful for a lot of people, but it is kind of the opposite of what I was asking about.

As far as I understand it the commercial repos try to solve two main concerns:

1. license compliance

2. security

Better performance and reliability are just additional benefits.

I only know the details for a certain Fortune 500 company. They don't want the builds to fetch packages from a site they don't control, and they certainly don't want "if it's not here, go look at this other one". The idea is more control about where the packages come from, not more flexibility.

I think if Cargo doesn't provide a way support alternative (possibly commercial) repos, it would be an obstacle to the adoption of Rust in the corporate world.

Re: Cargo: predictable dependency management

#129

Post by steveklabnik »

weinzierl wrote: post #128
steveklabnik wrote: post #62

Earlier quoted context omitted.

It's not easy, but it's possible. Everything is open source, and Cargo can easily be pointed at whatever host you want. The feature that I'd like to see but haven't found the time to implement is delegation: "look at this index first, but if it's not here, go look at this other one". Right now, if you spin up your own crates.io and point Cargo at it, it won't have any packages... which works for some people, but not…

> "look at this index first, but if it's not here, go look at this other one" I agree that this would be very helpful for a lot of people, but it is kind of the opposite of what I was asking about. As far as I understand it the commercial repos try to solve two main concerns: 1. license compliance 2. security Better performance and reliability are just additional benefits. I only know the details for a certain Fortun…

If you just want to ignore the broader OSS ecosystem, and run your own version of Crates.io behind a firewall, that's 100% supported today. The only real issue is that how to do so isn't particularly well-documented.

Re: Cargo: predictable dependency management

#130

Post by steveklabnik »

indatawetrust wrote: post #119

the subject will be on the outside but what are examples of applications developed with rust?

There's a lot of OSS stuff as well, (well, "a lot" for how old Rust is) but we just recently added https://www.rust-lang.org/friends.html to the website to showcase production users.
Post reply on HN