https://rust-lang-nursery.github.io/cli-wg/ – tracking repo: https://github.com/rust-lang-nursery/cli-wg/issues
Think of the default impls as more like
std::io::Error—yes, it would be very limiting if you had to write your whole program using that as your only error representation, but it's only designed for a narrow class of errors and the expectation is that non-trivial programs will write their own anyway.
I'm not sure about that :p
The quick to run part
Also ffmpeg is neither small nor fast but I'd still consider it a CLI
I love how the book tutorial is looking though!
(i was really surprised to see this philosophical line, though! but you are right, the assert_cli we have now is not the assert_cli we had before ;))
for the big rust 2018 preview release post?
I was hoping so, but I don't know. clap v3 builds, and even works with the structopt import (well after a quick fix I push tonight), but there is one major change left that I'm in the middle of doing which is probably the biggest API change (moving away from the stringly typed args) that isn't ready yet. So we could but people would need to note that major change still coming down the pipe
However if you return an Arg from a function the signature goes from
Arg<'_, '_> to Arg<'_, T>
any want to review draft for chapters on exit codes rust-lang-nursery/cli-wg#61 and using human panic? rust-lang-nursery/cli-wg#60
I still need to write a blog about what all has changed, how to test, and what's still left to do...but at least this part is done
It's late here and I have a Rust Reach meeting early in the morning, so more to follow on this topic tomorrow :wink:
I'll
I'm not sure when the Edition Preview announcement will go out… but I have some time to merge/review/write about stuff this morning :)
Hey, anyone up for some API brainstorming?
assert_cmd has an API for running Rust bins, see docs
- People want to expand it to pass features, see assert-rs/assert_cmd#34
- There is a tension in whether to pass
--targetbetween hurting the performance of a naive case or hurting the performance of a non-naive case and misleadingly reducing their coverage, see assert-rs/assert_cmd#4
I like how simple the current API is and would love to maintain it while adding features but it seems unlikely to happen. Instead, the best I can figure is we need to change the return type to some kind of builder that gives the user control over this stuff.
actually there might be another problem -- unless we do some really clever stuff, the randomized test order might require us to recompile this for every test
@killercup spent some time on thinking on what you said and have written up a proposal, see assert-rs/assert_cmd#44
ICYMI: I opened a bunch of of issues labeled 'book' to add/improve sections (most are the todos I added while writing the tutorial). feel free to discuss concrete content ideas and open new ones for sections you'd like to see: https://github.com/rust-lang-nursery/cli-wg/issues?q=is%3Aissue+is%3Aopen+label%3Abook
basically, the idea is to have these issues be concrete action items extracted from the tracking issues