Cargo, Rust's Package Manager (opens in new tab)

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.

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.

Now sure why you think the culture there doesn't respect semver.

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

Flipping your question around a bit: will package manager creators and maintainers ever develop better solutions to the use case of development rather than system administration so that we don't have to keep creating these language-specific tools?

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

Understand that enterprise OSes are not built on developer Macbooks. Enterprise distros have reproducible builds on automated systems with chroots that contain only what the package needs, no network access and sometimes the build happens inside a virtual machine. Its is almost ridiculous how after maven forgot the topic of being "offline" almost every tool released afterward has done the same mistake.

Understand that Linux distributions sell support and that means being able to rebuild a patched version of a failed package. So whatever dependencies are pinned in Cargo.toml or Gemfile is irrelevant. The OS maker will override them as a result of testing, patching or simply to share one dependency across multiple packages. Distros can't afford having one package per git revision used on a popular distro and then afford to fix the same security issue in all of them.

So having "cargo build" be able to override dependencies and instead look on the installed libraries with a command line switch or env variable helps the packager not having to rewrite the Cargo.toml in the package recipe.

Maven was probably the first tool that made packaging almost impossible and completely ignored the use-case of patching a component of the chain and be able to rebuild it completely.

Semantic versioning is great news, because it allows you to replace the dependencies for a common semantic version (not exactly the same).

For integrating with the C libraries not much needs to be done. If you support pkg-config then you cover 85% of the cases.

While technically the cache directory is a place where files can accumulate outside the view of a well documented and designed administrative tools, this is common problem shared with many tools including your favourite browser.

The quiet nature of the development process of Cargo was actually a response to the previous package management failures. The idea was not to publicise heavily before it was ready for dog fooding. This seems to have paid off.

The next features we're planning on working on are: - Supporting refs other than `master` from git packages

  1) Install latest version of Rust found here: http://www.rust-lang.org
  2) git clone --recursive git@github.com:rust-lang/cargo.git
  3) make
  4) make install (could be that sudo is needed for you)

The new tutorial will be based around 'real' Rust development, and so will assume Cargo.

That said, http://crates.io/ should have install instructions on the site. I'll open a ticket and get on that.

You cannot write comments in JSON, for instance.

    cargo read-manifest --manifest-path .

(I admit I have a bias against toml, but still...)