10 ms·
Cargo, Rust's Package Manager
- wunki 12y agoAnd here is the announcement from Yehuda Katz: https://mail.mozilla.org/pipermail/rust-dev/2014-June/010569.html https://mail.mozilla.org/pipermail/rust-dev/2014-June/010569...
- yazaddaruvala 12y agoWhy not just use JSON? Infact, why not just use npm's package.json?
- Svip 12y agoI 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.
- vlisivka 12y agoValid JSON: { comment: "The comment." }
- progx 12y agoExample 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 12y agoI 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?
- wtetzner 12y agoComments aren't just used to put notes in the file. They're also used to comment out code. Also, having to quote everything makes writing JSON by hand a pain. Why would you want to use it over a nicer format?
- mercurial 12y agoIt's sad to see that the guidelines about downvoting are clearly not respected.
- riquito 12y agoYou're not alone. YAML or similars are the right formats for these things, not JSON. Less clutter, comments separated from data, easier to read (by humans).
- bryanlarsen 12y agoYAML is a serialization format, not a configuration format.
- stormbrew 12y agoIt's really a configuration format that mistook itself for a serialization format. What I wouldn't do for a cut-down YAML standard with most of the serialization crap cut out.
- pandatigox 12y agoI 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...)
- the_mitsuhiko 12y agoWhich ones would that be?
- mateuszf 12y agoHow about s-expressions :) ?
- phloxicon 12y agoYAML is quite mature, clean, is a superset of JSON so people could use JSON if they wanted, and it's used for config files for pub, Dart's package manager. TOML doesn't seem mature enough.
- bjz_ 12y agoTOML is extremely simple. YAML on the other hand is incredibly hard to implement. JSON has no comments and is not really that nice for humans.
- nimish 12y agotoml is unstable and has no real spec + YAML has a well defined spec and is widely used?
- cmrx64 12y agoBecause comments.
- deleted 12y ago[deleted]
- cmrx64 12y agoThere isn't a lot of attachment to the exact manifest format used, but using json is clearly a step backwards!
- baq 12y agojson is only marginally easier to edit by hand than xml. also, comments.
- jdeseno 12y agoThe read-manifest command seems to output a JSON of your Cargo.toml if you have tools you'd like to use that require it: cargo read-manifest --manifest-path .
- illumen 12y agoYeah, why use some format that no one knows, and is harder to parse by other tools?
- nirvdrum 12y agoNot 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 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."
- steveklabnik 12y agoWhile this is true, NOTHING in Rust-land is stable yet, so it's not as big a deal.
- nirvdrum 12y agoThat's not really carte blanche to build everything on unstable technology. The point is things are supposed to be converging on stabilization. And a lot of what's unstable now is under the direct control of Rust. What TOML does or doesn't do is now a matter that needs to be worked out with Tom. It's not confidence-inspiring in the least. If the plan is to jettison TOML, then it's simply just an odd choice to use for a first cut. And from a purely perception manner, seemingly reaffirms concerns some have had about the bundler team building cargo (right or wrong).
- steveklabnik 12y agoThe plan isn't to jettison TOML, but even though it's 'unstable,' it hasn't changed in a very long time. And, given, uh, Tom, I doubt it will very much. He has better things to do these days. I can see an argument for INI files, but TOML is basically INI with some extensions. And YAML (which has no Rust parser, and nobody who wnats to write one) and JSON (which does have one in the standard library) are very poor configuration formats. Which one would you have preferred? It seems like a reasonable choice to me. > And from a purely perception manner, seemingly reaffirms concerns some have had about the bundler team building cargo (right or wrong). You could just spell out the personnel issues rather than being all FUDdy about it. (I'm friends with Yehuda, but also was room-mates with the current maintainer of Bundler (until very recently). Bundler isn't perfect, but lots of that had to do with people assuming a pre-1.0 project is stable, and upstream bullshit with RubyGems.)
- zimbatm 12y agoJSON is annoying with the commas. One forgotten comma or comma too much and the whole file doesn't parse.
- tomlu 12y agoHow 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 12y agoFrom announcement email: The next features we're planning on working on are: - Supporting refs other than `master` from git packages
- sp332 12y agoAs a workaround, I guess you could fork a specific version on your own github account, and use that as the dependency?
- drbawb 12y agoYou 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!
- kibwen 12y agoThe Rust folk are adamant about supporting versioned libraries out of the box, so support for this will definitely land before 1.0.
- jpgvm 12y agoI 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 12y agoThis 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)
- buster 12y agoI'm putting rust in $HOME/bin (and other self compiled software). You can change the default installation from /usr/local by running DESTDIR=$HOME make install
- btd 12y agoThere is no brew formula?
- aroch 12y agoFor rust? There is...cargo not so much aroch:~/staging/|⇒ brew info rust rust: stable 0.10 (bottled), HEAD http://www.rust-lang.org/ http://www.rust-lang.org/ /usr/local/Cellar/rust/0.10 (74 files, 174M) * Poured from bottle From: https://github.com/Homebrew/homebrew/commits/master/Library/Formula/rust.rb https://github.com/Homebrew/homebrew/commits/master/Library/... aroch:~/staging/|⇒ brew info cargo Error: No available formula for cargo
- sigzero 12y agoRust has a brew package. Cargo is new so it may be a day or three before it gets out there too.
- cevn 12y agoHmm, 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.
- ithkuil 12y agoI'd love if $ cargo cult would build a new project/module from a template.
- deleted 12y ago[deleted]
- tempodox 12y agoYes, absolutely. Cargo cult doesn't have the best reputation, but this would be an opportunity to cherish it :-)
- steveklabnik 12y agoThe plan is for that to be `cargo project`, but that might be a fun alias. :)
- FrozenCow 12y agoI 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 12y agoYes, 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 .
- bjz_ 12y agoYes, it will be supported. The Bundler guys were specifically contracted by Mozilla to sort out the mess. They are actually using Rust in production at the moment, so the have a big stake in its future. 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.
- mellisarob 12y agoThis is good news. a better alternate to conventional techniques
- deleted 12y ago[deleted]
- tempodox 12y agoThis 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...
- Sanddancer 12y agoWill 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?
- sanderjd 12y agoI 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 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?
- kibwen 12y agoThis 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/ https://nixos.org/nix/
- eddyb 12y agoThey 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.
- sanderjd 12y agoYeah, nix does look pretty awesome and aware of (even actively designed for )both the system administration and development use cases. If it becomes the native package manager for some popular operating systems, I may have to eat my words about language-specific solutions.
- sigzero 12y agoIf 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 12y agoI 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 12y agoI 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 12y ago> 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 12y ago> 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.
- bryanlarsen 12y agoThis 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.
- steveklabnik 12y agoNote 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.
- ionforce 12y agoWhy would uno not work on 1.4?
- steveklabnik 12y agoWhen you declare an x.y.z dependency, tools that use SemVer (like Bundler, which is the biggest influence on Cargo) assume x.y.(>z). So, a 1.4.12 dependency says "Anything greater than 1.4.12, but less than 1.5.0." When you declare an x.y dependency, tools that use SemVer assumes x.(>y). So, a 1.4 dependency says "Anything greater than 1.4.anything, but less than 2.anything.anything". This is assuming the ~> operator, if it was =, it would ONLY be 1.14.2, which is even more restrictive. The project _should_ work, which is why Cargo is using this modified version of ~>.
- mercurial 12y agoWhat 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.
- bfrog 12y agoThis 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.
- pjmlp 12y agoWhat about binary only dependencies?
- steveklabnik 12y agoThis should absolutely be handled in some good way. I think right now you'd just set the script attribute to something empty, but that's obviously a hack.
- Locke1689 12y agoI 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).
- cies 12y agoLearn two things: 1. Wycats (Yehuda Katz) is on Rust apparently :) 2. `.toml` -- some crossbreed YAML/INI file format that I like
- stormbrew 12y agoIt'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.
- dreamdu5t 12y agoWhile 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 12y agoThe goal is to use package manager defaults and community pressure to keep things on the straight and narrow. We'll see how it goes!