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

141–146 of 146 posts

Re: Cargo: predictable dependency management

#141

Post by cm3 »

dbaupp wrote: post #139
cm3 wrote: post #124

Earlier quoted context omitted.

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.

Ah, it is a total non sequitur, unrelated to what servo encounters when changing Rust versions?

I don't understand what you're saying. I suggested that linux builds of rust+cargo ought to be done as musl-static (not for targeting musl) so that a single download works on both Ubuntu and Alpine. Now we have only glibc builds. Yes, it's not related to servo, but it is relevant to you mentioning glibc, though this is off-topic so let's stop arguing.

Re: Cargo: predictable dependency management

#142

Post by dbaupp »

cm3 wrote: post #141
dbaupp wrote: post #139

Earlier quoted context omitted.

Ah, it is a total non sequitur, unrelated to what servo encounters when changing Rust versions?

I don't understand what you're saying. I suggested that linux builds of rust+cargo ought to be done as musl-static (not for targeting musl) so that a single download works on both Ubuntu and Alpine. Now we have only glibc builds. Yes, it's not related to servo, but it is relevant to you mentioning glibc, though this is off-topic so let's stop arguing.

I think you should go back and re-read the conversation, particularly kibwen's comment above and your reply: they seem to be totally unconnected. I was trying to understand how you thought they (Servo upgrading Rust versions and a musl-compiled rustc) were related, I was not arguing. There is in fact no mention of glibc until your comments, nor is there any implication in my comments that I don't understand what musl does nor do I disagree that it is useful (in fact, I used Rust's easy ability to link binaries against musl just a few days ago). This discussion is purely prompted by me trying to understand why you thought it made sense to talk about musl on a seemingly unrelated comment... maybe there was some insightful connection I missed, but it seems not.

Re: Cargo: predictable dependency management

#143

Post by cm3 »

dbaupp wrote: post #142
cm3 wrote: post #141

Earlier quoted context omitted.

I don't understand what you're saying. I suggested that linux builds of rust+cargo ought to be done as musl-static (not for targeting musl) so that a single download works on both Ubuntu and Alpine. Now we have only glibc builds. Yes, it's not related to servo, but it is relevant to you mentioning glibc, though this is off-topic so let's stop arguing.

I think you should go back and re-read the conversation, particularly kibwen's comment above and your reply: they seem to be totally unconnected. I was trying to understand how you thought they (Servo upgrading Rust versions and a musl-compiled rustc) were related, I was not arguing. There is in fact no mention of glibc until your comments, nor is there any implication in my comments that I don't understand what musl…

You're right.

Re: Cargo: predictable dependency management

#144

Post by technomancy »

gnoway wrote: post #123
technomancy wrote: post #121

Earlier quoted context omitted.

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

Passwords are usually under the complexity threshold of copyrightability, but keypairs aren't.

But secrets can have many other kinds too, like accidentally publishing code which is under a restrictive license.

Re: Cargo: predictable dependency management

#145

Post by kibwen »

airless_bar wrote: post #131
kibwen wrote: post #100

Earlier quoted context omitted.

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

If course global name-spacing has something to do with it! What's the difference between a "username" resulting in nike/package-name and a package called nike-package-name? Not much in practice. Name-spacing doesn't mean "add another made up name entry somewhere". That's why people who thought about these issues out-sourced this concern completely: Prove your ownership of nike.com and you can publish as nike.com. Sud…

I'm not sure what you're trying to say. The problem exists independently of whether or not global namespacing is implemented by a package repository. Nike would have just as much authority to remove a "nike" package in a global namespace as it would to remove "bob/nike" (which is to say, almost no authority whatsoever).

I have no dog in the fight over whether or not a global namespace is a good idea, but it's tiresome to see irrelevant arguments being trotted out against global namespacing.

Re: Cargo: predictable dependency management

#146

Post by airless_bar »

kibwen wrote: post #145
airless_bar wrote: post #131

Earlier quoted context omitted.

If course global name-spacing has something to do with it! What's the difference between a "username" resulting in nike/package-name and a package called nike-package-name? Not much in practice. Name-spacing doesn't mean "add another made up name entry somewhere". That's why people who thought about these issues out-sourced this concern completely: Prove your ownership of nike.com and you can publish as nike.com. Sud…

I'm not sure what you're trying to say. The problem exists independently of whether or not global namespacing is implemented by a package repository. Nike would have just as much authority to remove a "nike" package in a global namespace as it would to remove "bob/nike" (which is to say, almost no authority whatsoever). I have no dog in the fight over whether or not a global namespace is a good idea, but it's tiresom…

Jesus Christ, just get on with times.

Even Node has overtaken Rust.

Post reply on HN