Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Sep 10 06:48
    ashutoshrishi commented #33
  • Aug 26 12:49

    killercup on gh-pages

    Deploy rust-lang-nursery/cli-wg… (compare)

  • Aug 26 12:45
    Dylan-DPC commented #141
  • Aug 26 12:45
    Dylan-DPC synchronize #58
  • Aug 26 12:45

    Dylan-DPC on master

    Fix fuzzing broken link (#141) (compare)

  • Aug 26 12:45
    Dylan-DPC closed #141
  • Aug 26 12:45
    Dylan-DPC closed #140
  • Aug 26 12:38
    frewsxcv opened #141
  • Aug 26 12:14
    rusty-snake commented #140
  • Aug 26 12:01
    killercup commented #140
  • Aug 26 12:01
    killercup commented #140
  • Aug 26 11:42
    rusty-snake opened #140
  • Jul 22 00:28
    lbeckman314 synchronize #139
  • Jul 22 00:08
    lbeckman314 opened #139
  • Jul 20 13:28
    stappersg commented #137
  • Jul 20 13:24
    stappersg commented #138
  • Jul 20 13:21
    stappersg opened #138
  • Jul 20 11:44
    Dylan-DPC commented #137
  • Jul 19 20:08
    killercup commented #137
  • Jul 19 20:07
    stappersg opened #137
Jacob Finkelman
@Eh2406
here is a simple test of the install script https://travis-ci.org/Eh2406/cargo/jobs/484542914#L621-L631
Ed Page
@epage
Not seeing any output from your before_deploy. Looking at your deploy, I see on: tags: true but I'm not seeing any tags in your travis history
https://travis-ci.org/holmgr/cargo-sweep/builds
Yeah, install.sh assumes the binary will be available at https://github.com/holmgr/cargo-sweep/releases which is what trust deploys to.
So you can just look at that page to see whether it is install.sh or your CI setup
Jacob Finkelman
@Eh2406
So you're working hypothesis is @holmgr made the release in the wrong way?
Ed Page
@epage
Not wrong, just missing a step (tagging). You can tag after the fact
Jacob Finkelman
@Eh2406
Ed Page
@epage
Oh, you're right
"/^v\\d+\\.\\d+\\.\\d+.*$/".travis.yml is only configured for tags that start with v.
So either changing .travis.yml or adding a new tag v0.4.0 should get it kick started
Jacob Finkelman
@Eh2406
so changing that line to "/^v?\\d+\\.\\d+\\.\\d+.*$/" will make it work?
Ed Page
@epage
For future tags, yes
Jacob Finkelman
@Eh2406
I do not have permissions on the repo, to test myself, but do you have instructions for how to trigger a build on the existing release?
Ed Page
@epage
If the build existed, you'd see a rebuild button
but for a tag that it ignored, I have no idea
Jacob Finkelman
@Eh2406
Ok, thanks for all the help!
Ed Page
@epage
Like I said, you could always re-tag the commit with v0.4.0 and then travis will pick it up
Ed Page
@epage
Ah, it assumes v as well
Jacob Finkelman
@Eh2406
does that mean that the name needs to start with a v for install to work
Ed Page
@epage
Yup
Jacob Finkelman
@Eh2406
ok closing my pr.
Ed Page
@epage
It has to know what tags are relevant
Jacob Finkelman
@Eh2406
I closed my pr to cargo sweep holmgr/cargo-sweep#21
Jacob Finkelman
@Eh2406
I don't have perms, so hopefully @holmgr can retag things this weekend, and we will see if it is fully working.
Jacob Finkelman
@Eh2406
set up travis on my fork, and pushed a tag: https://github.com/Eh2406/cargo-sweep/releases/tag/v0.4.0
Jacob Finkelman
@Eh2406
It picked up the tag and tried to deploy but it has his secrets, so it did not work.
https://travis-ci.org/Eh2406/cargo-sweep/jobs/484559290#L267
https://travis-ci.org/Eh2406/cargo-sweep/jobs/484559285#L647
So it looks like changing the tags will work.
Thanks for the help!
Ed Page
@epage
You're welcome
Ed Page
@epage
RE assert_cmd 1.0
This is in the works.
I've been letting it sit to gather feedback before bumping to 1.0. This led to assert-rs/assert_cmd#69 and am in that same holding pattern; waiting for people to upgrade, try it out, and report back problems

assert_fs is in a similar boat but less controversial in my mind; I'd be willing to bump that any time.

Should they both go in the same announcement post?

Pascal Hertleif
@killercup
@epage morning! yeah, wanted to ping you about that. at the all hands cli meeting yesterday we talked about assert-rs for a bit -- it's probably the most complete of all the items we had on the WG todo list from last year!
Pascal Hertleif
@killercup
what are your immediate plans for these crates? i haven't been following in detail, but _cmd and _fs both look like there are no breaking changes happening soon, right? if we can squish the last known bugs, pushing them to 1.0 sounds like a good idea.
i'd love to get one or more blog posts out explaining to people how these crates fit together and how amazing predicates is. i can totally (help) write this
this might also be the right time to make assert_cli re-export the 1.0 crates, as well as helpers like tempfile
Ed Page
@epage
I would put them at release candidate stage (and have been for a while). I've taken care of any 1.0 blocking bugs but I consider the recent API breakers to be uncertain enough that I was planning on waiting a month or so to see what feedback trickles in.
So the current plan for assert_cli is to just aggregate the various CLI-related testing crates? At one point you were talking about a higher level, abstraction like in the waltz tests
Oh and two things I'd like to see but not blocking 1.0
  • Directory diffing. Still been mulling over what'd be the appropriate API
  • Snapshot testing as you suggested. I'm waiting to see how the other snapshot testing crates mature
Katharina
@spacekookie
:wave:
waves at Pascal from 1 metre away
Jeremy Wright
@jmwright

Hello everyone. Is there a standard, cross-platform way to add tab completion to Rust CLIs? The solutions I've found in my searches look like they probably won't be cross-platform. Here are a couple of links I've found.
rust-lang/rustup.rs#278

https://www.reddit.com/r/rust/comments/4qvltw/claprs_can_now_generate_bash_tabcompletion/

I expect to use a combination of static (clap-rs generated) and dynamic tab completion (think path completion on the command line). I figured this group would be the most well connected with the best practices for this currently.

Pascal Hertleif
@killercup
@epage sounds good! i meant that once we have cmd and fs at 1.0, we should start building up assert-cli again from that, and iterate on its design from that
and yeah, i agree, dir diff and snapshots would be great to have. have you seen the progress on the insta crate?
Ed Page
@epage
been watching it.
Daniel Sockwell
@codesections
@jmwright What sort of cross-platform support are you looking for beyond what Clap provides? It does Bash, Powershell, Zsh, Fish, and Elvish, which seems to have most platforms covered
Jeremy Wright
@jmwright
@codesections Thanks for the reply. The only reference I found was to a bash autocomplete script, so I thought that only bash was supported. Looks like I was wrong.
Katharina
@spacekookie
Just FYI, we renamed the github organisation to rust-cli to be more in-line with the rest of the working groups
Daniel Sockwell
@codesections
That makes sense. The old name was pretty fun, but I can see the logic
Gargi Sharma
@gs0510
Hi all! I am looking for repositories with "good-first-issue" to contribute for this working group. I am looking at the repos under "https://github.com/rust-cli". Am I looking at the right place? Thanks!