
Cargo, Rust's Package Manager - wunki
http://crates.io
======
bryanlarsen
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. Truly respecting semver
would have required these patch level updates to get a new major number.

~~~
Argorak
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...](https://github.com/rails/rails/blob/master/guides/source/maintenance_policy.md)

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.

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

~~~
matdes
MRI _still_ doesn't follow semver but core doesn't really give a crap.

~~~
steveklabnik
They claim "Semantic Versioning type" versioning, which is, of course, not
SemVer, but I think what your parent was referring to.

[https://www.ruby-lang.org/en/news/2013/12/21/ruby-version-
po...](https://www.ruby-lang.org/en/news/2013/12/21/ruby-version-policy-
changes-with-2-1-0/)

------
ithkuil
I'd love if

$ cargo cult

would build a new project/module from a template.

~~~
steveklabnik
The plan is for that to be `cargo project`, but that might be a fun alias. :)

------
wunki
And here is the announcement from Yehuda Katz:

[https://mail.mozilla.org/pipermail/rust-
dev/2014-June/010569...](https://mail.mozilla.org/pipermail/rust-
dev/2014-June/010569.html)

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

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

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

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

------
FrozenCow
I haven't been following the development of this package manager, but previous
attempts at making a package manager for Rust have failed. Is this package
manager supported officially now? I really hope it will stick around.

~~~
dbaupp
Yes, the developers are actually domain experts being paid by Mozilla. The
release of this website also coincided with the move of the source repository
into the rust-lang organisation: [https://github.com/rust-
lang/cargo](https://github.com/rust-lang/cargo) .

------
tomlu
How do you pin a dependency to a particular version or git sha? I can't find
anything in the FAQ or docs that implies that it's possible.

~~~
cgag
From announcement email:

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

~~~
sp332
As a workaround, I guess you could fork a specific version on your own github
account, and use that as the dependency?

~~~
drbawb
You don't even need to fork it on Github, Cargo is just passing the URI
straight to the git tooling.

You can keep it on your local filesystem and reference it w/
`file:///path/to/repo.git` -- you can also use SSH and HTTPS URIs from any
other repository host, not just github!

So you could just clone the repo to some `vendor` directory and move `master`
to whatever version you want!

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

------
dreamdu5t
While I support semantic versioning, people need to be aware that it's only as
good as the package maintainer. I have used packages that have
(unintentionally) broke semver conformity. Nothing really stops an author from
releasing breaking changes when going from "1.2.1" to "1.2.2".

~~~
wycats
The goal is to use package manager defaults and community pressure to keep
things on the straight and narrow. We'll see how it goes!

------
tempodox
This is very welcome news, indeed. I will have to give it a try as soon as I
can make the time.

I hope it will be more stable and work better than the Haskell package
manager, Cabal. I literally _never_ got that to work on any machine. It would
typically destroy itself while attempting to update itself...

------
jpgvm
I would really love to see some docs on how to actually install and get
started with Cargo.

It doesn't ship with Rust and the docs on GitHub and crates.io are not very
enlightening.

~~~
wunki
This was how I installed it (Mac):

    
    
      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)

~~~
btd
There is no brew formula?

~~~
sigzero
Rust has a brew package. Cargo is new so it may be a day or three before it
gets out there too.

~~~
cevn
Hmm, well, rust's brew seems a little outdated (0.10), so if you are intent on
using Cargo soon, I would recommend on building rust yourself or grabbing a
new binary from their website.

~~~
sanderjd
There is a homebrew-cask of Rust's nightly binary. I think this should work:

    
    
      brew tap caskroom/cask
      brew install brew-cask
      brew tap caskroom/versions
      brew cask install rust-nightly

~~~
kolev
Stuff being either in Cask or Homebrew is just terrible. Homebrew also has a
versions tap. Those two projects should combine efforts and remove ambiguity.

~~~
sanderjd
I 100% agree with you. It took me like an hour to figure out where I thought
it made sense to put rust-nightly, and I'm still not really sure I did it
right. But it works and is _way_ better than the morning compilation cronjob I
used to use.

~~~
kolev
I agree, it works, but we need to keep pressing those guys... or contribute.
Cask still doesn't have reinstall/upgrade. As far as I know, Homebrew can't
upgrade packages with head versions, and, worst pain of all - Homebrew doesn't
support Yosemite or any unreleased OS X version. Being a tool for developers
primarily, all the above are must-haves!

------
cies
Learn two things:

1\. Wycats (Yehuda Katz) is on Rust apparently :)

2\. `.toml` -- some crossbreed YAML/INI file format that I like

~~~
stormbrew
It'd be really nice if it didn't impose a hard choice of json-ish to use for
the manifest, even though that's a rather small thing. Just don't want to be
stuck with toml if it doesn't gain wider acceptance than it has so far.

------
pjmlp
What about binary only dependencies?

~~~
Locke1689
I think mixed is also very important. For example, sometimes you really do
only have a binary dependency (e.g., .NET assemblies), while other times, you
may have a binary + source dependency (e.g., library + header files).

------
mellisarob
This is good news. a better alternate to conventional techniques

------
sigzero
If someone can log into github and enter a ticket to say no to toml. Yaml
would be perfect for it and it is mature and people already know it.

~~~
steveklabnik
I don't have strong feelings about toml, but the YAML spec is incredibly
complicated, and has way too many features for a config file format. And
security vulnerabilities O_O

~~~
thinkpad20
I don't know about the security vulnerabilities, but it works fine as a config
file format (we use it at my company for a lot of in-house stuff). I had a
similar reaction to the language. Even if not YAML, why not just use JSON?
It's universal, dead simple to use and understand, has extensive libraries in
just about any language, etc...

That said it's not that big of a deal. At least it's not an in-house markup
like Haskell's cabal...

~~~
steveklabnik
> I don't know about the security vulnerabilities,

About 14 months ago, it caused some of the most serious vulnerabilities in the
Ruby on Rails world ever:
[http://tenderlovemaking.com/2013/02/06/yaml-f7u12.html](http://tenderlovemaking.com/2013/02/06/yaml-f7u12.html)

> why not just use JSON?

JSON is not really human-editable. Those quotes and commas, ugh! Also, JSON
lacks comments.

The vulnerabilities in YAML (which is a superset of JSON, by the way) point at
why YAML and JSON both aren't appropriate for configuration: they are
_serialization_ formats. Configuration isn't what they're built for.

And you're right, it's really just not a huge deal in any way. Especially once
we have `cargo project` to autogenerate the basics.

~~~
mercurial
> About 14 months ago, it caused some of the most serious vulnerabilities in
> the Ruby on Rails world ever:
> [http://tenderlovemaking.com/2013/02/06/yaml-f7u12.html](http://tenderlovemaking.com/2013/02/06/yaml-f7u12.html)

Live by eval, die by eval. But more seriously, nobody is forcing a Rust YAML
library to support arbitrary structure deserialization (or maybe as an
optional switch). I don't think you'd want such a switch on in a build system
configuration file.

~~~
steveklabnik
Then you're not supporting YAML, you're supporting your own subset of YAML.

~~~
mercurial
That's one way to look at it. On the other hand, when a format presents
useful, but potentially dangerous characteristics (eg, XML entities
expansion), it is entirely sensible to offer a way to not take them into
account.

~~~
steveklabnik
Quite fair. Depends on what kind of tradeoff you're looking for: this
personally makes me search for a new format. It's reasonable to make a
different choice.

~~~
bronson
I don't even think that's fair. What happens when everyone implements their
own pet subset of a standard?

~~~
mercurial
It's not an hypothetical future, you can often disable dangerous features in
XML parsers. It seems sensible to me to do the same with YAML parsers.

------
yazaddaruvala
Why not just use JSON?

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

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

~~~
progx
Example from the website in json

    
    
        {
          'package': {
             'name': 'hello-world',
             'version': '0.1.0',
             'authors': [ 'wycats@example.com' ]
          },
          'bin': {
            'name': 'hello-world',
            'comment': 'the name of the executable to generate'
          }
        }
    

So where is the problem ?

And you have the advantage, that other tools can use the complete file
including the comment. In TOML you need an extra parser to grab the comment.

~~~
simias
I don't really care what format the cargo files use (that's just an
inconsequential bikeshed as far as I'm concerned) but in your example
"comment" is really not a comment. I would expect to be able to put free-form
comments anywhere I want and have them thrown away by the parser.

Your solution works fine for docstrings, but comments and docstrings are not
the same thing (although many languages that don't support docstrings in the
syntax hack them together using comments, admittedly).

But beyond that, what's the argument for switching to json? Is there some kind
of intercompatibility with npm/Node.js to be gained?

