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

61–70 of 146 posts

Re: Cargo: predictable dependency management

#61

Post by weinzierl »

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…

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

Re: Cargo: predictable dependency management

#62

Post by steveklabnik »

weinzierl wrote: post #61
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…

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

Re: Cargo: predictable dependency management

#63

Post by pyre »

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…

What would be useful is a sort of "caching proxy" that could have various knobs to handle situations like:

- crates.io is down

- crates.io says this cached package doesn't exist.

- etc...

Re: Cargo: predictable dependency management

#64

Post by imron »

rsaarelm wrote: post #17
akhilcacharya wrote: post #5

Earlier quoted context omitted.

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

The Meson build system http://mesonbuild.com/ seems to have a package manager like dependency management system.

It's also very quick and easy to get projects up and running.

For *nix based platforms Meson is now my go to build manager for c++ projects.

Re: Cargo: predictable dependency management

#65

Post by dalailambda »

xkarga00 wrote: post #42

I have been working as a Go programmer for the past two years and I really love the language but dependency management has been one of the biggest pains for me. Godep really sucks (that's what we use in my current gig - we plan on switching to Glide, still haven't played around with it) and I am not sure I like the fact that I need to go out in the wild and choose between the rest of the existing solutions. I would p…

In my experience Glide is the closest to a modern package manager for Go.

Re: Cargo: predictable dependency management

#66

Post by gpm »

cm3 wrote: post #44

It's great that Raph's line-breaking code has been reused, but in contrast to Mozilla projects any contribution to it will now require assigning copyright to Google (like Ubuntu or Microsoft's CLA require as well). At least it's a tiny piece, so may not hurt too much in terms of prevented contributions.

Or just forking it, it's released under a open source license.

This wouldn't be the first time Servo has forked a dependency, for example they maintain a fork of glutin (library that handles opening windows) because they want certain features that upstream doesn't.

https://github.com/servo/glutin

Re: Cargo: predictable dependency management

#67

Post by ybx »

weinzierl wrote: post #61
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…

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

What would be really nice is if there were a system like how debian, ubuntu, etc. does it, and allow for official (and unofficial) mirrors

Re: Cargo: predictable dependency management

#68

Post by ecnahc515 »

pyre wrote: post #63
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…

What would be useful is a sort of "caching proxy" that could have various knobs to handle situations like: - crates.io is down - crates.io says this cached package doesn't exist. - etc...

This is already possible today with existing caching proxies. This is a great way to make your CI/builds more reliable and quicker.

Re: Cargo: predictable dependency management

#69

Post by jalami »

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 know it wouldn't really fix issues like left-pad, but I would really like namespaced packages similar to the way Github does them. I think group ownership would be more explicit and understood. Top level packages encourages sqatting and small/old/unmaintained packages getting names that people would misunderstand for something else. I understand a lot of that is on the user of the library to research before downloading, but intuitiveness is a virtue. It's true packages could just be called eg. reactjs-node-bridge or something as opposed to reactjs/node-bridge, but anyone can prefix deceptively.

Cargo addresses the namespacing concern here http://internals.rust-lang.org/t/crates-io-package-policies/...

Re: Cargo: predictable dependency management

#70

Post by tatterdemalion »

incepted wrote: post #52
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…

> 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.
Post reply on HN