Consider porting to Rust

[huonw]

We now have cargo install, so distribution is as easy as pip, and, Rust is awesome.

Notes:

• there's a lot of .travis.yml's installing the Python version,
• it'd be great to be completely 100% compatible
• People test on travis with a wide variety of Rust versions:
  • cargo install can't be assumed to work (only nightly at the time of writing, but maybe 1.4 and/or 1.5-beta in a week)
  • it should be a goal to work on Rust 1.0 if at all possible to not be a restriction (and/or make an assessment about what versions people are testing with)
  • there needs to be an installation procedure as short as pip install travis-cargo<0.2 and/or cargo install travis-cargo --vers 0.1 that'll work on all reasonable versions (i.e. not just cargo install)
• might be good to publish new version of the Python that's a shim that installs the Rust one (e.g. installing travis-cargo 0.1.9999999 will do some magic to install the "real" travis-cargo from crates.io)
  • it could detect if cargo install fails due to being missing (or the travis-installed Rust version being too old), and fall back to "installing" itself, or manually doing an installation of the Rust one (this doesn't work for a too-old Rust). Autoinstalling a Python version would mean there should be a while of feature parity between the Rust and the Python for a while.
  • alternatively, detect if Rust/Cargo is too old and install a sufficiently new one to install travis-cargo in some sort of scoped way to not affect the rest of the world (static linking means it should be fine to compile travis-cargo, install and then blow away that compiler)

[jonas-schievink]

The 1.0 constraint makes this extremely hard, since many libraries don't support it (and even more only have CI on stable, so they can easily break).

In case someone manages to do this: Please make sure Travis doesn't compile dozens of crates for installing travis-cargo - The best thing to do would be to add a cache to the example .travis.yml, but that kind of plays badly with cargo install (see this comment)

[euclio]

I've written a proof-of-concept port at https://github.com/euclio/travis-cargo-rust.

• The CLI should be 100% compatible with the current version
• The code builds on 1.0.0, but the travis build uses cargo install (no fallback right now), so the build fails on anything except the main trains
• Minimal dependencies (regex, docopt, and rustc-serialize)

The code is pretty much a direct port of the Python, so it isn't particularly rustic (lots of unwrap()s). If we think this is worthwhile, I can clean up the code and open a PR alongside the Python version.

[euclio]

Friendly ping @huonw

[huonw]

@euclio wow, nice work! Unfortunately, I don't have time right now to dig in, but hopefully I'll be able to find some soon.

---

Speaking to the air: another realisation I had was that we could just distribute binaries, e.g. as generated by https://github.com/japaric/rust-everywhere, avoiding entirely any version compatibility problems and the need to rely on cargo install (etc.): just download the single binary and chmod it +x. Getting the binaries out takes a little more set-up on travis-cargo's part, but seems like it would make like easier going forward.

[euclio]

Cool, great to hear about the rust-everywhere solution. I'm happy to get the ball rolling further on this once you get a chance to do an initial review (unfortunately I've been pretty busy myself). Would it help if I started a PR branch?

There are already a few things I'd like to change:

• Better error handling (already mentioned this)
• Replacing version detection with rustc-version
• Would you rather use docopt or clap for arguments (it seems official Rust projects tend to use clap?).

[huonw]

I took a look and it looks pretty good. I submitted https://github.com/euclio/travis-cargo-rust/pull/1 as a result.

[roblabla]

I took a different approach over at https://github.com/roblabla/cargo-travis , linking directly against the cargo crate.