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

51–60 of 127 posts

Re: Cargo, Rust's Package Manager

#51

Post by steveklabnik »

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

Note that this is a sliiiightly modified SemVer: in SemVer, these three things would conflict. It would be strict SemVer if uno depended on ~>1.3, and dos on ~>1.4.

We hypothesize that this difference works better for AOT compiled languages. And since it's pre-1.0, it's all good. This is the 'we'll watch this closely and adjust' from the email: it might not be okay.

Re: Cargo, Rust's Package Manager

#52

Post by mercurial »

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

What would be fantastic is if a Cargo repo could refuse a package which doesn't follow follow this policy (try to upload a new minor version with an incompatible ABI, get 400 Bad Request as a response). Of course, it won't save you from a change in semantics, but it would already be a good step forward.

Re: Cargo, Rust's Package Manager

#53

Post by Argorak »

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

Re: Cargo, Rust's Package Manager

#54

Post by alextgordon »

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?

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 tested with, not some later version that a sysadmin decides it "probably should work with".

Re: Cargo, Rust's Package Manager

#55

Post by bryanlarsen »

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…

Rails, for better or worse, is the flagship project of Ruby, and shapes the Ruby culture quite strongly.

I would much prefer Rails 20 than the current situation. If you want to make a major marketing level move, introduce a codename or something. Separate marketing from semantics.

Re: Cargo, Rust's Package Manager

#56

Post by bryanlarsen »

alextgordon wrote: post #54
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?

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 much better shape if they followed those assumptions too.

Re: Cargo, Rust's Package Manager

#57

Post by steveklabnik »

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…

Cargo assumes the former.

Re: Cargo, Rust's Package Manager

#58

Post by bryanlarsen »

Svip wrote: post #4
yazaddaruvala wrote: post #3

Why not just use JSON? Infact, why not just use npm's package.json?

I may not be a majority here, but I see JSON as a data transportation format, while I see TOML or YAML as configuration formats. You cannot write comments in JSON, for instance.

YAML is a serialization format, not a configuration format.

Re: Cargo, Rust's Package Manager

#59

Post by steveklabnik »

nirvdrum wrote: post #33
illumen wrote: post #21

Earlier quoted context omitted.

Yeah, why use some format that no one knows, and is harder to parse by other tools?

Not only that, but TOML is still considered unstable by its author. Granted, it hasn't been updated in several months. But that seems like a shaky foundation to be building on top of. From: https://github.com/toml-lang/toml "Latest tagged version: v0.2.0. Be warned, this spec is still changing a lot. Until it's marked as 1.0, you should assume that it is unstable and act accordingly."

While this is true, NOTHING in Rust-land is stable yet, so it's not as big a deal.

Re: Cargo, Rust's Package Manager

#60

Post by ionforce »

steveklabnik wrote: post #51
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.…

Note that this is a sliiiightly modified SemVer: in SemVer, these three things would conflict. It would be strict SemVer if uno depended on ~>1.3, and dos on ~>1.4. We hypothesize that this difference works better for AOT compiled languages. And since it's pre-1.0, it's all good. This is the 'we'll watch this closely and adjust' from the email: it might not be okay.

Why would uno not work on 1.4?
Post reply on HN