Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cargo, Rust's Package Manager

crates.io

Post reply on HN
Print view View original

81–90 of 127 posts

Re: Cargo, Rust's Package Manager

#81

Post by awj »

Argorak wrote: post #53
bryanlarsen wrote: post #42

This is sweet: For example, if I have three packages: - uno depends on json 1.3.6 - dos depends on json 1.4.12 - tres depends on json 2.1.0 Cargo will use json 1.4.12 for uno and dos, and json 2.1.0 for tres. Hopefully rust builds a culture that respects semantic versioning better than the Ruby & Node cultures do. That has to start at the top. There were several Rails 2.3.X releases with minor ABI incompatibilities.…

Don't equate Rails with Ruby (some projects follow semver very closely). Rails follows a shifted semver version, as documented here: https://github.com/rails/rails/blob/master/guides/source/mai... Bumps from 4.x to 4.y might contain smaller breaking changes. For a large project as Rails, I find that reasonable, otherwise, we'd be at Rails 20 by now, which also doesn't quite give a good sense of how the project evolve…

MRI didn't follow semver up until recently, and even now it has some caveats about it.

Ruby as an ecosystem doesn't really care for semver. Some projects follow it anyways, which I can respect, but they aren't the norm.

Re: Cargo, Rust's Package Manager

#82

Post by awj »

Sanddancer wrote: post #39

Will this play nicely with the package management tools OSes already have, or is this going to end up being yet another source for files/packages to accumulate that are outside the view of well-documented and designed administrative tools?

Until the various OS package managers stop pretending they are a universe unto themselves, this problem will continue. Languages have to distribute libraries across all of their host systems, so focusing on support for any particular package manager (or small subset thereof) doesn't buy much.

Hopefully the cargo team can come up with a solution that works a little better here, but I wouldn't hold my breath.

Re: Cargo, Rust's Package Manager

#83

Post by kodablah »

the_mitsuhiko wrote: post #11
pandatigox wrote: post #5

Earlier quoted context omitted.

I think that's a good point. Why use .toml when we have better alternatives already? (I admit I have a bias against toml, but still...)

Which ones would that be?

HOCON: https://github.com/typesafehub/config

Re: Cargo, Rust's Package Manager

#84

Post by bfrog »

This looks like yet more awesome stuff coming out of the Rust camp.

I'm pretty excited to see Teepee and Rust come together so I can really give it a spin doing what I'm currently doing daily for a job.

Re: Cargo, Rust's Package Manager

#85

Post by nirvdrum »

steveklabnik wrote: post #79
nirvdrum wrote: post #76

Earlier quoted context omitted.

That's a fairly weak argument. If it's not going to change, then maybe some outreach should be done to get him to tag it 1.0. Otherwise you're opening yourself up to the exact same issue you outline as an issue for Bundler -- people assumping a pre-1.0 project is stable. As long as there's the option for someone to say "this is pre 1.0 so I can change it whenever" it's going to cause concern because most of us have b…

> If it's not going to change, then maybe some outreach should be done to get him to tag it 1.0. Absolutely. Let me make an issue about that: https://github.com/rust-lang/cargo/issues/46 If he doesn't respond, I will email him. > As for the FUDdiness... Thanks! Since the points are enumerated, I can refute them: > * You can't override a dependency: You can, in modern Bundlers. But the transitive dependency issue is i…

I think we wound up on the same page, even if a circuitous route. So I don't want to continue beating up on bundler. But I guess I'm going to take one more parting shot and mention that a lot of its execution performance is due to thor as well (at least when I've profiled). Using binstubs rather than "bundle exec" can be a good deal faster.

I feel compelled to mention it because this seems to be a clear case where an aesthetic DSL was chosen over performance and it can't really be fixed without a backwards-incompatible change. Rust and Ruby are two different beasts and I get that. I just hope that performance is a core design consideration for Cargo (I have no idea if it is or if it's just a nice-to-have).

Airing dirty laundry is hardly ever pleasant. I'm certainly not immune to my own set of WTFs. I legitimately just want to make sure Cargo comes out awesome. And I much appreciate Mozilla's commitment to having a standard dependency resolution tool when Rust ships.

Re: Cargo, Rust's Package Manager

#86

Post by pjmlp »

bryanlarsen wrote: post #56
alextgordon wrote: post #54

Earlier quoted context omitted.

Ha! There is nothing well-designed about the mutually incompatible, political hell that is OS package managers. The best solution (as taken by npm, virtualenv and others) is to install libraries locally to the project that is building them. That way, package management becomes the sole concern of the build system. "Accumulation" is a good thing, it means each project has the exact version of a package that it was tes…

OS package managers make two assumptions: - that packages follow semver - that the OS packagers are in a better position to test package combinations. If the author releases a new version of libfoo, and A, B and C in an OS repo depend on libfoo, then the OS packagers do not release a new version of libfoo until the tests for A, B & C pass. These are two good assumptions, and the language package world would be in muc…

Which OS are "OS package managers"? There is a world out there greater than GNU/Linux.

Re: Cargo, Rust's Package Manager

#88

Post by steveklabnik »

nirvdrum wrote: post #85
steveklabnik wrote: post #79

Earlier quoted context omitted.

> If it's not going to change, then maybe some outreach should be done to get him to tag it 1.0. Absolutely. Let me make an issue about that: https://github.com/rust-lang/cargo/issues/46 If he doesn't respond, I will email him. > As for the FUDdiness... Thanks! Since the points are enumerated, I can refute them: > * You can't override a dependency: You can, in modern Bundlers. But the transitive dependency issue is i…

I think we wound up on the same page, even if a circuitous route. So I don't want to continue beating up on bundler. But I guess I'm going to take one more parting shot and mention that a lot of its execution performance is due to thor as well (at least when I've profiled). Using binstubs rather than "bundle exec" can be a good deal faster. I feel compelled to mention it because this seems to be a clear case where an…

Sounds good. I'll make one tiny parting shot to your parting shot, and we'll be done. :)

> Using binstubs rather than "bundle exec" can be a good deal faster.

Absolutely, which is why we switched to them with Rails. It is a tough problem, though, and given Ruby's constraints. In my testing, it's the startup time that's the issue, not Thor, which is because `bundle exec` has to re-start the interpreter multiple times, and binstubs don't. Anyway.

> I just hope that performance is a core design consideration for Cargo

Rust people already feel the pain of very long rustc compiles, so while I'm not sure that it's an overriding concern, given the Rust world's concern with performance in general, I expect it to be way better. Ruby has always kinda thrown performance to the wolves.

> I legitimately just want to make sure Cargo comes out awesome.

We all do. And I'll admit to being a bit sensitive to 'lol bundler,' which I feel is often said without fully understanding the problem space, which is admittedly large. Not that you are doing that, but I have seen similar comments elsewhere. Once you explain the details, it's pretty clear why Bundler does what it does.

Anyway, yes: let's make Cargo 1.0 and Rust 1.0 super awesome! I'm really excited that we're taking this step forward. It's a huge day for Rust.

Re: Cargo, Rust's Package Manager

#90

Post by eddyb »

kibwen wrote: post #74
sanderjd wrote: post #44

Earlier quoted context omitted.

I think it would be just as easy to package rust programs using OS native package management as anything else, and I'm sure packages will be made for popular things for common package managers. But OS native package managers are a royal pain to use when actively developing on a project that has some dependencies, and bespoke Makefiles are a very imperfect solution. Flipping your question around a bit: will package ma…

This is an insightful point. Nix is the only package manager I'm aware of that seems like it could fit the bill: https://nixos.org/nix/

They already have automated Haskell packages from cabal, it shouldn't be hard to integrate cargo with nix once it's more stable.

You wouldn't even require upstream NixOS packages, just place built cargo packages in the nix store, using it like a cache. Then upstream NixOS channels could start accumulating cargo packages, making cargo dependency "builds" faster.

Post reply on HN