owned this note
owned this note
Published
Linked with GitHub
# Future of the Rust CLI WG
**Note:** This document is meant as collaboration point and for taking notes at meetings, not for publishing.
Where: https://meet.jit.si/Rust-CLI-WG
When: First Monday of the Month 1800 UTC
- https://everytimezone.com/s/f6f40d18
Potential topics: [focus areas](https://github.com/rust-cli/team#focus-areas)
## Action Items
August 22, 2022
- [ ] Have book link out to clap tutorials, reference cookbook, etc
- [ ] Reach out to rain about merging efforts, see https://rust-cli-recommendations.sunshowers.io/
- [ ] Write blog post re-introducing ourselves
September 5, 2022
- [ ] ricky: Create rosetta for config
- Skeleton: https://github.com/rosetta-rs/config-rosetta-rs
Oktober 3, 2022
- [ ] @matthiasbeyer: document release process for clap-{permission,port}-flag
- [ ] @matthiasbeyer: Think harder about config-rs rethink
- [ ] Read up https://github.com/rust-cli/team/issues/7
March 6, 2023
- [ ] @epage: follow up with matthiasbeyer
August 7, 2023
- [ ] @epage: Reach out to Jane about color-eyre and anstream
## Sync meeting - November 6, 2023
Attendees: epage, pksunkra, andreas
### Agenda
- [cargo and hyperlinks](https://github.com/rust-lang/cargo/pull/12889)
- [trait for styling](https://docs.rs/stylish/latest/stylish/)
- Issue: api stability
- Could we get into stdib?
- auto-handling not in anstream yet, unsure if should due to complexity
- cargo and dynamic CLIs
- andreas: log mixed with dynamic output, could get off when they interleave
- andreas: logging and general output not playing well with each other
- andreas: internally, they put everything to one sink to make things play well
- andreas: could tracing have a standardized way to work well with others?
- [The Book](https://github.com/rust-cli/book)
- Revamp the book later to talk about the CLI patterns from:
- https://clig.dev/
- https://rust-cli-recommendations.sunshowers.io/
- [Change in clap value names](https://github.com/clap-rs/clap/issues/5156)
- Showing literals might encourage better practices
- Literals has the benefit of having less duplication
## Sync meeting - October 2, 2023
No show
## Sync meeting - August 7, 2023
Attendees: epage, pksunkra, andreas
### Agenda
- Dynamic completions for clap
- https://github.com/clap-rs/clap/issues/5058
- minimal new shell: https://github.com/clap-rs/clap/blob/master/clap_complete/src/dynamic/shells/bash.rs
- completest: https://docs.rs/completest/
- Is there a way to test if autocomplete really works? (Though dynamic complete shouldn't need this per CLI anymore...)
- CLI testing in markdown
- Livebook, livemd (jupyter in markdown)
- trycmd
- FB's upcoming tool: https://github.com/facebookincubator/scrut (not yet public)
- Pull completest in?
- TUI testing
- A little more progress
- Packaging system
- https://github.com/termapps/publisher
- How should a CLI exit out?
- color-eyre vs human_panic
- proc_exit
- How should WG-CLI engage?
- As per previous discussion, create a discussion repo in rust-cli org with existing threads for all workstreams.
- Introduce the workstreams in the blog and ask users for feedback pointing to the above discussion repo.
```rust
/// General representation for a completion in various shells.
/// This includes the necessary information to build how a completion looks
/// for each specific shell.
pub struct Completion {
/// When selected, the value that will be autocompleted in its entirity.
pub value: OsString,
/// What to show in autocomplete instead of the value.
/// Useful when the value benefits a more user-friendly version.
pub display: OsString,
/// Additional help information about the completion that can be shown
/// alongside the completion.
pub help: Option<OsString>,
}
/// List of completions to be grouped together. For example subcomands may be
/// shown separately from options or flags.
pub struct CompletionGroup {
/// The name to show above the completion group.
/// Supported shells: zsh.
pub name: Option<OsString>,
/// List of completions for this group.
completions: Vec<Completion>,
}
```
## Sync meeting - July 3, 2023
Attendees: epage, pksunkra, andreas
### Agenda
May 1, 2023
- [x] @epage Close out issues on concolor
- [x] @pksunkara Create PR for implementing colorchoice-clap in terms of clap::ColorChoice
June 1, 2023
- [x] @epage Ping concolor users for migrating off (https://github.com/rust-cli/concolor/issues/47)
July 1, 2023
- [x] @epage Archive concolor repo
## Sync meeting - June 5, 2023
Attendees:
### Agenda
## Sync meeting - May 1, 2023
Attendees: pksunkara, epage
### Agenda
- Move https://github.com/rust-cli/concolor/issues/29 & other concolor issues
- TUI testing update
- Selected `vt100` as a base for the library
- Trying to use it in `dialouger` tests before separating it out and making it a library
- Need to actually refactor `dialouger` into using `crossterm`
- How to diff
- XML diff
- Diffs but no inline diff styling, just user styling
- For non-visible escape codes, normalize? Explicitly render all non-visible characters but also apply ansi styles?
- clap-color-flag - Remove?
## Sync meeting - April 3, 2023
Attendees: epage, pksunkara
### Agenda
- Meeting time: keep the same
- epage: IsTerminal is in FCP: https://github.com/rust-lang/rust/issues/98070
- epage: `anstyle` moved to rust-cli
- epage: clap 4.2 (using `anstyle`) released
- Complaint of [superficially metrics](https://hachyderm.io/@djc/110133860398752356)
- concolor:
- `concolor` now defunct
- not many users
- not tying things together
- `concolor-clap` should move to `concolor-override`
- So name' for `concolor-override`, `concolor-query`
- Port to anstream
- env_logger: was waiting on further feedback before adopting it
- Deprecate existing styling API
- Use anstream internally
- tracing-subscriber?
- Feel things out
- color_eyre?
- Update book
- Anstyle
- Requires going 1.0
- Plan: clap
- Hopefuls: termion, ratatui
- TUI testing
- Final contenders: vt100, termwiz
- termwiz goes beyond what we need because its the core of wezterm
- Two methods: takes a text and emulates that, or write an emulate interacting with crossterm's API
- install tools
- https://github.com/termapps/publisher/blob/master/src/repositories/aur.rs
- cargo-dist
- cargo-deb
- cargo-wxs
- Holy envy: https://goreleaser.com/
## Sync meeting - March 6, 2023
Attendees: epage, pksunkara
### Agenda
- Update on config-rs-ng
- anstyle update
- `anstyle` is planned to be a stable API for describing styling so other crates can put it in their API
- [`anstyle-wincon`](https://github.com/epage/anstyle/tree/main/crates/anstyle-wincon) created
- [`anstyle-parse`](https://github.com/epage/anstyle/tree/main/crates/anstyle-parse) is in progress
- Next is `anstream` as a replacement for `termcolor`
- or `anstyle-stream` or something
- Look at `pastel colorcheck` command
- Request: Please audit `anstyle` API
- pavan: Use `anstyle-stream` once it's ready and give feedback.
- Once mature, move anstyle over to rust-cli
- Deployment plan
- termion integration in hopes to get tui to use anstyle
- tui integration or get them to use anstyle directly
- nu_ansi_term?
- console integration
- cursive?
- Don't need to be pushy with crates like yansi directly using anstyle
- Might not be able to get desired API
- Anstyle is only useful for these crates when they are being used by other libraries, like clap will be and hopefully tui
- Impact of annoyance of adapter is diminished
- Meeting time?
- Use https://lettucemeet.com/ to find a new time?
- TUI testing
- vt100
- ptytest
- portable-pty
- term-transcript
## Sync meeting - February 6, 2023
Attendees: epage, pksunkara
### Agenda
- epage: updated human-panic
- pavan: TUI testing
- vte (alacrity's crate) was too low level + ansi only, not key bindings
- vt100 does screen emulation
- TUI libs?
- pavan: just use crossterm, otherwise use TUI
- crossterm seems more active (dev, community) than termion, console is dead
- cursive seemed less maintained TUI
## ~~Sync meeting - January 2, 2023~~
Canceled for holidays
## Sync meeting - December 5, 2022
Attendees: @epage @matthiasbeyer
### Agenda
- Demonstrate [renovate](https://github.com/rust-cli/argfile/blob/main/.github/renovate.json5)
- Demonstrate [requiring status checks](https://github.com/rust-cli/argfile/blob/main/.github/settings.yml#L46)
- config-rs and kdl (https://hachyderm.io/@zkat@toot.cat/109462090972935844)
- matthiasbeyer will be some focus time on config-rs
- epage: pulled away by toml-rs (and toml_edit and nom..., yak shaving)
## Sync meeting - November 7, 2022
Run by Pavan
Attendees: @pksunkara @matthiasbeyer @gankra
### Updates
- @pksunkara & @matthiasbeyer looked into [backpack](https://github.com/rusty-ferris-club/backpack)
- It's nothing new or exciting, just a generator
- Has less features than other generators in other ecosystems
- Only pro is that it's a rust tool
- @matthiasbeyer still needs to document the release process for clap-{permission,port}-flag, because no release was necessary yet
- Maybe wait for clap v5, before updating and doing the releases
- @matthiasbeyer config-rs-ng
- Repository: https://github.com/matthiasbeyer/config-rs-ng
- config-rs has some issues internally on how it extracts the data
- Made a new repository to develop new approach for the same API
- Get some beta testers and if everything goes well, replace the old one with the new one
- Question: Write a vision doc? https://github.com/mehcode/config-rs/pull/376
- Examples similar to https://rust-lang.github.io/wg-async/vision/shiny_future/users_manual.html
- Matthias to start one on github and we will finalize
- @matthiasbeyer rexpect now maintained and in rust-cli-WG \o/
- https://github.com/rust-cli/rexpect
- @gankra starting on "cargo-dist" project (currently private)
- scope currently a bit fuzzy but basically conceptually it picks up *after* cargo-release
- tunes build for production (split-debuginfo, etc.)
- packages up zips/installers
- replaces the need for everyone to write non-portable github ci actions..?
- produces machine-readable manifests for further tooling like package managers..?
### Agenda
- @matthiasbeyer wondering whether config-rs need both sync loading and async loading
- Would be better to discuss this after the vision doc examples
- That doc should contain description of expected users
- Need to get the loading story right before worrying about the config updating in middle
- Layers might lead to more problems with async
- Loading config should be as simple as one call
- Example: https://github.com/pksunkara/reign/blob/master/examples/full/src/main.rs#L28
Action items
- [x] @matthiasbeyer: Write a vision doc for config-rs (https://github.com/mehcode/config-rs/pull/376)
- See: https://github.com/matthiasbeyer/config-rs-ng/pull/6
## Sync meeting - October 3, 2022
- @matthiasbeyer is trying to get maintainership of the following crates:
- [x] "exitcode", current Maintainer unresponsive (as of 2022-09-07)
- See also `proc-exit`
- Access to `proc-exit` as a default is good enough, so we're fine
- [x] "rexpect": https://github.com/philippkeller/rexpect/issues/43
- (I see that this crate does not necessarily fall into the "CLI" space)
- Fits within testing but has wider role, does it fit within rust-cli?
- Checking with other maintainers
- Why move?
- Show maintainer
- increase "bus factor"
- more people can release/update
- Ability to change repo setting
- https://beyermatthias.de/changelog-management
- Keeping lights on
- clap v4 updates
- epage: Add rust-cli/Maintainers
- epage: documented release
- matthiasbeyer: documente
- matthiasbeyer: looking into cargo-release (trivial release, consistency)
- ricky: documented and released
- What is current state config?
- See rosetta repo
- https://github.com/rosetta-rs/config-rosetta-rs
- confy and clap
- clap_derive
- Arguments that are required, either from arg or file
- Showing default in clap (or config's current value)
- Forced to deal with `Option` when mixing soruces
- Gankra's company tried `twelf`
- issues with merging non-homogeneous schemas
- npm packages have a field like THIS but cargo.toml has THAT
- ag_dubs "it's not worse than config-rs"
- never got to the clap stuff, got caught on the above first
- [ ] add to rosetta comparison
- Focus Area: [Config](https://github.com/rust-cli/team/labels/A-config)
- See also https://github.com/clap-rs/clap/discussions/2763
Action items
- [x] @matthiasbeyer: Talk to [rexpect](https://github.com/philippkeller/rexpect) people about moving the crate to CLI-WG
- [x] https://github.com/philippkeller/rexpect/issues/71
- [x] @matthiasbeyer: look into cargo-release
## Sync meeting - September 5, 2022
### Agenda
- https://github.com/rust-lang/team/pull/808
- Waiting on spacekookie
- What is the purpose of WG-CLI?
- Identify gaps
- Working on gaps if needed
- Can we keep up?
- Focus on mentorship / identifying "help-wanted" tasks / projects
- (Passively) Maintaining crates/books
- Keep the lights on
- Not to do features
- BoF or SiG to collaborate among CLI authors
- Set aspirations / long term vision
- Ricky: state of crates and maintianers
- https://github.com/rust-cli
- Specifically confy
- Is confy still relevant?
- https://lib.rs/crates/figment
- https://lib.rs/crates/config
- https://github.com/mehcode/config-rs/issues/371 (diff config/figment)
- ~7 individuals asking for releases
- Creating a https://github.com/rosetta-rs?
- https://github.com/rust-cli/team/labels
- Redundancy in releases
- Create rosetta repo for config and then follow up next time
- Automate and document processes
- e.g. cargo-release with Action to create release
- backpack to push out scaffolding changes?
- https://github.com/rusty-ferris-club/backpack
- epage: Last call on [clap --help](https://github.com/clap-rs/clap/issues/4132)
- burntsushi, sharkdp, ducaale prefer all caps (wanting man-page like experience)
- joshtriplett, gankra, and sharkdp prefer the green (but don't care about the yellow)
- Planning to collapse usage to single line minimum (rather than 2 line)
- Thinkinf of dropping indentation to 2 (but really don't want to do test update)
Action items
- [x] Automate, document release processes, verify rust-cli can release
- [x] epage: clap, clap-verbosity-flag, argfile, human-panic, concolor, termtree, proc-exit, roff-rs, man
- [x] matthiasbeyer: clap-port-flag, clap-permission-flag
- Seems as there no release process in place
- Not sure how to verify whether rust-cli can release
- ricky: I verified by going to the [crates.io page](https://crates.io/crates/clap-port-flag) and looking for `rust-cli/maintainers`, if you're in that group you can release and members here are :)
- [x] ricky: confy
- There appears to be no standard to releasing, tags exist for the following versions (`0.4.0`, `0.3.1`, `0.3.0`), this goes back to 28-05-2018 so any further back is of no use
- perferred release process
- Users/Contributors/Maintainers put in a PR with a feature rollup request (possibily a tool to grab latest commits since last release for a CHANGELOG or release notes) OR we merge a PR that is vitial and requires a x.y.z + 0.0.1 release
- Approval/merge from maintiner means releasing now
- Create a tag for the release with the release notes in the tag
- Push new version to crates.io
- [x] epage: look into [expect-test](https://docs.rs/expect-test/latest/expect_test/)
- [x] pavan, matthiasbeyer: research [backpack](https://github.com/rusty-ferris-club/backpack)
## Sync meeting - August 22, 2022
### Agenda
- work streams
- Clap
- Wider clap ecosystem
- mangen, completions, clap_fs, flag crates, etc
- Ergonomics
- Ease of solving CLI related problems including filesystem interactions
- stdlib: upstreaming and standardizing pain points
- https://github.com/rust-lang/rust/pull/98033
- https://github.com/rust-lang/rust/pull/95290
- terminal size?
- Why standardize? What is the line for standardizing?
- Terminal formatting
- concolor, anstyle, etc
- Concolor's fate is dependent on how anstyle works out
- Later update book with what we feel should be done
- anstyle will be for public apis
- anstyle-stream for outputting (will be used inside color libraries)
- owo-colors or yansi could still fill a role in language integration which is not planned for anstyle atm
- Terminal interaction for CLI
- Basic animation like progress within cargo
- Doesn't have full control, user will also be doing their own output
- e.g. dialoguer
- Diagnostic reporting
- proc-exit
- human-panic / bugreport
- anyhow / thiserror
- log (which logger?) vs tracing
- Config
- TUI
- Full control of terminal output
- Holy envy: textual
- See https://www.textualize.io/blog/posts/7-things-about-terminals
- Holy envy: charm
- See https://charm.sh/
- Testing: One-shot CLI
- e.g. snapbox
- Color in snapbox: https://github.com/assert-rs/trycmd/issues/124
- Testing: Time and user dependent interaction (animation, TUI, etc)
- Including pexpect-style (basic input/output)
- Both TUI and terminal interactions (e.g. dialoguer)
- Categories
- Pure text based interactions (e.g. pexpect)
- TUI based interactions
- e.g. full TUIs but even dialoguer-like libraries and simple progress bars
- Need full terminal emulation logic (e.g. vte, pyte in python)
- Where should term-transcript go? In snapbox?
- Snapbox: https://github.com/assert-rs/trycmd/issues/124
- Packaging / distribution
- Publisher - Utility tool to easily manager and maintain distributions for CLI
- stager: https://crates.io/crates/stager
- Publisher would probably use stager
- https://github.com/rust-cli/team/issues/8
- https://crates.io/crates/cargo-bundle
- Documenting your CLI
- tldr generation
- manpages generation (e.g. roff)
- Documentation for creating CLIs
- The Book
- Scope / Approach
- Today
- Quick tutorial
- In-depth topics
- Proposal: guided example program
- Cover all streams
- Link out to in-depth in each crate, working to improve them
- rust-cli itself
- https://github.com/rust-cli/team
- Github org and sub-teams
- https://github.com/rust-lang/
- https://www.rust-lang.org/governance/wgs/cli
- Ping people for moving to alumni
- concolor
- Blocked on
- anstyle maturing to see what needs come up
- sign off from termcolor to ensure it meets their needs
- anstyle
- anstyle: Allow library users to define color schemes independent of implementation
- Use case: https://github.com/clap-rs/clap/issues/3234
- anstyle-stream: Decouple format site from the related output stream and its capabilities
- Format site will use ansi escape codes. The caller will then use a special type of stdout/stderr that will either pass-through, strip colors, downgrade colors, or convert to wincon
- Use case: https://github.com/clap-rs/clap/issues/3108
- Use case: https://github.com/clap-rs/clap/issues/1433
- clap flags
- CLI testing libraries
- Older CLI
- https://docs.rs/assert_cmd/latest/assert_cmd/
- https://docs.rs/assert_fs/latest/assert_fs/
- Newer CLI
- https://docs.rs/snapbox/latest/snapbox/
- https://docs.rs/trycmd/latest/trycmd/
- TUI testing?
- https://github.com/mitsuhiko/dialoguer/pull/183#issuecomment-1219379600
- Generally, TUI has been out of scope of WG-CLI
- isatty crate vs lib
- wg-cli team on rust-lang.org
- The Book
- Particularly, how to handle crate recommendations, see https://github.com/rust-cli/book/pull/157
- But in general, what does the future of the book look like?
- I've suggested to rain to merge theirs with the book: https://rust-cli-recommendations.sunshowers.io/index.htm
- Monthly meeting
- First monday of the month
- 6pm UTC
- Archive many repos or move to clap
- Create rosetta-rs org for https://www.reddit.com/r/rust/comments/w24rmg/github_epageparsebenchmarksrs/
- When do we make crates official?
- Blog post introducing what we are doing?
- Wait until we've pinged all team members about status?
### Action Items
- [x] Document work streams on team repo
- [x] Create issue labels in the team for them
- [x] Create calendar invite
- [x] Contact existing team members for status
- [x] Add pksunkara, make epage the leader: https://github.com/rust-lang/team/pull/808
- [x] Create rosetta-rs org for https://www.reddit.com/r/rust/comments/w24rmg/github_epageparsebenchmarksrs/, see https://github.com/rosetta-rs
- [x] Archive many repos or move to clap
- [x] Do not advertise wg-cli discord channel
- [x] Link book to rosetta: https://github.com/rosetta-rs
- [x] Make sure the book mentions the cli-tui discord channel
- [x] Expand book to cover all streams (either loosely covered or an issue exists)
## Sync meeting – October, 2020
Date/time: Monday, 2020-10-05 18:00 UTC
Where: https://meet.jit.si/Rust-CLI-WG-2020
### Agenda
(in no particular order)
* Status check-in
* Recurring meeting invite for calendar
## Sync meeting – June, 2020
Date/time: Monday, 2020-06-01 18:00 UTC
Where: https://meet.jit.si/Rust-CLI-WG-2020
Present: codesections, pksunkara
### Agenda
(in no particular order)
## Sync meeting – May, 2020
Date/time: Monday, 2020-05-04 18:00 UTC
Where: https://meet.jit.si/Rust-CLI-WG-2020
Present: codesections, killercup, rotty
### Agenda
(in no particular order)
* Status check-in:
* rotty:
* mailing list archive: still not subscribed, and mbox file from spacekookie not yet imported
* Rust infrastructure team might be interested in setting up their own public-inbox instance
* A subdomain delegation to rotty's instance might happen in the meantime
* killercup:
* Instead of doing anything regarding error handling himself, he nerdsniped Jane into doing
[something cool](https://github.com/yaahc/color-eyre)
* Random links
* https://crates.io/crates/codespan
* https://adventures.michaelfbryan.com/posts/linkchecker/
* https://gitlab.com/rotty/btm/-/blob/master/btm/test-data/ip-packet.btm
* https://github.com/tootsuite/flodgatt
* https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=6c842605d0aec0291f9b2b0e3d4bb218 is way better than this example https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=0469967b9ecf3fe26867c0500edda342
## Sync meeting – April, 2020
Date/time: Monday, 2020-04-06 18:00 UTC
Where: https://meet.jit.si/Rust-CLI-WG-2020
Present: pksunkara, spacekookie, rotty, killercup
### Agenda
(in no particular order)
* Status check-in:
* rotty
* e-mail related weirdness: cli mailing list is modifying From e-mail headers
* Confidence that importing the ML archive is going to work (plaintext only filter was a problem)
* Otherwise the archive seems to be okay
* pksunkara
* re-organising clap issues and figuring out a plan for clap v3.0
* Looking for more help with documentation
* Function docs are pretty good, not much needed
* Better README, and introduction docs, guides, and examples
* Work out strategy on how to handle structopt 2 -> clap 3 migrations
* Automation tool? How is this implemented
* Mix between deprecation warnings and automatic code fixes
* Probably can't use rustfix (since it's meant to consume rustc diagnostics),
but maybe have a look at [rerast](https://github.com/google/rerast)
* spacekookie
* Hasn't really done anything this month (neither packaging or translations)
* killercup:
* Not much to say, but working on pretty cli logging
and [backtraces](https://crates.io/crates/color-backtrace)
* Mailing list archive?
* rotty: http://inbox.r0tty.org/
* When is it going live?
* What does it need for this to happen?
* How to subscribe the archive to the mailing list?
* https://github.com/rust-lang/team/pull/299
* https://github.com/rust-lang/team/pull/215
* How to get a different domain pointed at the archive
* spacekookie posted on the Rust zulip about it
* Recurring meeting invite for calendar
* [Community Calendar experiment](https://cloud.rewrite.in.rs/apps/calendar/p/LZ7LyH5Piq6bmL3L-coMmmqy4dQCGKY62-gK3seE28webFswaG-ZFCPdksTt9C4JkXX-zKazYeAP4bYwnDya-eAw8zYfFYZZ2PP36-GL7iLCzNP6akwALE-b9FTPoPLtarCEDxn/dayGridMonth/now)
* Showcase
* [Fondant](https://github.com/NerdyPepper/fondant)
* Plans for next month
* spacekookie
* sync up with codesections about translations
* figure out a good way to improve build infra for distributions (see guix)
* pksunkara
* Work through clap issues, do a beta _soon_
* rotty
* Work on a library https://gitlab.com/rotty/btm
* Next meeting organizer: rotty
* Send an e-mail before the event (+ invite)
* TODO: figure out the calendar situation
## Sync meeting – March, 2020
Date/time: Monday, 2020-03-02 18:00 UTC
Where: https://meet.jit.si/Rust-CLI-WG-2020
Present: epage, codesections, rotty, pksunkara, CreepySkeleton
### Agenda
(in no particular order)
* CLI framework (pksunkara)
* Like https://oclif.io/
* More expansive than https://github.com/killercup/quicli
* Suggestion: collect building blocks and create a prototype to demonstrage idea
* Config problems?
* epage mentioned avoiding crates due to limits
* epage vaguely remembers error reporting (validation postponed until after merge)
* What epage did for cargo-release
* https://github.com/sunng87/cargo-release/blob/master/src/config.rs
* https://github.com/sunng87/cargo-release/blob/master/src/main.rs#L941
* Status check-in:
* Packaging proposals (as discussed via ML)
* rotty: to get in distributions, source-packages best
* rotty: Cargo.lock files are at conflict with distributions wanting to consolidate package versions
* rotty: https://gitlab.com/rotty/cargo-parcel/
* rotty: https://www.gnu.org/software/stow/
* Mailing list archive?
* rotty: http://inbox.r0tty.org/
* Waiting on some files
* pksunkara: mentioned https://hyperkitty.readthedocs.io/en/latest/
* Plans for next month
* Next meeting organizer: pksunkara
## Sync meeting – Feb, 2020
Date/time: Monday, 2020-02-03 18:00 UTC
Where: https://meet.jit.si/Rust-CLI-WG-2020
Present: Pascal, Ed Page, codesections (Daniel), pksunkara, rotty
### Agenda
(in no particular order)
* Status check-in:
* Packaging proposals (as discussed via ML)
* Did not discuss (Kathariana took lead and not pressent)
* documentation crate (as discussed via ML)
* bikeshed the name? Stick with `man` (even though it will do more than just man pages)
* Discussion of Clap
* Continue to target as first-class
* But remain agnostic re: others (and support where possible)
* Consider moving some crates to Clap org.
* Mailing list archive?
* Plans for next month
* Next meeting organizer: Ed Page
## Sync meeting - Jan, 2020
Date/time: Monday, 2020-01-06 18:00 UTC
Where: https://meet.jit.si/Rust-CLI-WG-2020
Present: Katharina, Matthias, codesections (Daniel)
### Agenda
(in no particular order)
* Happy new year
* Talking about
* What happened since the last meeting?
* There are semi-regular team-lead meetings kookie attends.
* There's the Mail-WG thing (unrelated to us)
* Codesections worked on a format for the man crate
* Kookie thought about packaging of/for Rust applications
* How to make native package integration easier?
* Post on ML coming later this week
* Idea for `man` crate/docs in general:
* One plaintext file as single source of truth (per language) for
* man (roff)
* --help (clap/txt)
* README (md)
* tldr (md)
* Use a format compatable with `scdoc` (Drew DeVault's man page syntax)
* Idea: use `!(X…)!` to indicate which output format text should be rendered for
* Where `X` is one or more letters corrisponding to output formats
* e.g.: `!(MT Example )!` would render "Example" for man page and tldr output (but not others)
### Next meeting
codesections will organise: 2020-02-03
## Email to Niko
Hey Niko,
just an update on how things are going in the CLI-WG. We've been
talking a lot about what we want to focus on and how we want to do
it.
Fundamentally we decided to remain the "CLI Working Group" (not
changing the name, or scope), and instead focus our efforts on a few
aspects in the space we are already covering.
We also changed our organisational structure a bit. Pascal will stop
being the de-facto group leader, and instead we will select someone to
be the leader for a period of time (for example 6 or 12
months). Previously we decided to not have any formal leadership, which
meant that either things didn't get done or Pascal did them after
all. I volunteered to do this job for now, so I'll be the point of
contact for other teams, including core.
We also decided to have regular sync meetings via video chat, to
discuss progress being made on different issues. We created a Matrix
room on matrix.org that will replace the Discord room (there's no
great way to communicate this on the website yet), and we're
thinking about how we could use a mailing list in the future.
There is a WIP PR to the teams repo representing these changes (#188).
If you have any questions, let me know.
Cheers,
Katharina
## Sync meeting in week 49
Date/time: Monday, 2019-12-02 18:00 UTC
Where: https://meet.jit.si/Rust-CLI-WG-2020
Present: Katharina, Pascal, Matthias, codesections (Daniel)
### Agenda
(in no particular order)
- Decisions decisions decisions!
- Review teams repo PR: https://github.com/rust-lang/team/pull/188
- All hands meeting slots?
- Yes: Grab 1 for now
- Responsible: Pascal
- Move repo out of rust-lang-nursery?
- Yes: to rust-cli/meta
- Responsible: Katharina
- Move book to wherever other books live?
- Yes: to rust-cli/book (but make sure the links to rust-lang-nursery.github.io/cli-wg stay alive)
- Responsible: Katharina
- Contribute something to upstream Rust roadmap?
- No: we don't really have a roadmap
- Responsible: Katharina (msg Nico)
- Public announcements (when and what about?)
- Yes, but work on an announcement
- Responsible: Katharina and Matthias
- Where? [inside rust](https://blog.rust-lang.org/inside-rust/) seems to be the hot new thing?
- clap 3.0 and man pages planning
- What is the desired architecture of the man generator?
- Katharina:
- More information than `--help`
- Generate one page per subcommand
- Pascal:
- Keep man/roff generation separate from how to get information from libraries
- Katharina:
- maybe build something that can import strings into clap help, man page, etc
- Daniel:
- Keep a single source of truth to keep things from getting out of sync
- Katharina:
- *thoughts on translations here*
- Questions:
- Where does additional data come from?
- Translations?
- go through crates and do releases!
- What crates do we have?
- thunder (Katharina)
- comfy (Katharina)
- roff-rs (Daniel)
- man (Daniel)
- clap-md (Matthias)
- clap-{port,permission,log,verbosity}-flag (Pascal)
- human-panic (2.0 roadmap exists) (Katharina)
- paw (?)
- Mailing list functions (discussions? Tracking issues?)
- Do we care about all things being in a single place?
- What features do we want? (usability, target demographic, ...)
- Postpone to async discussion (Matthias and Katharina will work on concept post)
- Working group name and new terminal scope
- Don't announce scope expantion before actually doing work in that area
- Maybe get in touch with TUI developers (cursive, ncurses bindings, ...) first
- Maybe change name later (future bikeshed,... rather not(?))
- Getting people right in the matrix channel
- Pascal* will fix the website by pointing people at [this](https://github.com/rust-lang/www.rust-lang.org/blob/e770231372604486abd995fcf1532e28b5ea0611/templates/governance/group-team.hbs#L21-L25) and [this](https://github.com/rust-lang/team/blob/c2141e1e162d1da2139cbb31872bdf78222f1461/rust_team_data/src/v1.rs#L53)
- Advertise Matrix channel in the Discord channel header (like embedded-wg)
- Next meeting:
- facilitated by: Matthias :sparkles:
- on: January 6 at 19:00 UTC
## Sync meeting in week 48
Date/time: Monday, 2019-11-25 20:00 UTC+1
Where: https://meet.jit.si/Rust-CLI-WG-2020
Present: Pascal, Katharina, Matthias, Daniel, Ed, Dylan
### Agenda
(please add topics to discuss!)
0. Saying hello and waiting for people to join. (5min)
1. 1 sentence of what you want the CLI WG to do next year (1min per person)
2. Decisions decisions decisions (45min)
1. WG focus
- Proposal: Internal refocus on Terminal apps ecosystem (user/ working) group - Yes, but lets not bikeshed the name now
- Proposal: Error-handling working group / Collaborate with other WGs on Error-handling? - Keep internal first, then collaborate with others. Possible create a new group in the future
- Proposal: Collaborate more with packaging "working group" - Keep internal first, then collaborate with others. Possible create a new group in the future
2. WG "rebranding"?
- Proposal: Keep "working group" for consitency - No, figure out new internal structure first
3. Where to have discussions
- Proposal: Keep discord - defer
- Proposal: Matrix in addition to discord - Yes (managed by Daniel, Matthias, Katharina)
- Proposal: move async "internal" communication to mailing list - Yes (Katharina will do teams PR)
- Proposal: Use rust-lang/team mailing list + public-inbox - Yes (Katharina)
- Proposal: Split off group of people to document what we want and figure out how to get it (Katharina will organise meeting - the regular meeting)
4. Regular meetings
- Proposal: Have regular meetings - Yes
- Proposal: Meet ever first Monday of the month at 19:00 UTC on Jitsi - Yes-ish
- Maybe: Rust meeting at Congress
5. Team leads
- Proposal: Appoint one "contact person" for the next 6 months - Yes
- Katharina is the chosen one
- Proposal: Appoint the facilitator of the next meeting at the end of each meeting
- Katharina is the first facilitator for Dec 2
3. Short term action items
- NOTHING! \o/ (go have fun)
- defered
4. To talk about at a future meeting
- clap 3.0 and man pages planning
- All hands meeting slots?
- Move repo?
- Move book?
- Contribute something to upstream Rust roadmap?
- go through crates and do releases!
## Notes
- Ed
- Get `assert-cmd` and `assert-cli` (?) to 1.0!
- Create tooling to help people with licensing and publishing
- Daniel
- Provide guidance on best practices
- Get stuff to 1.0 and then promote those crates
- Have a more consistent ecosystem with mature crates
- Matthias
- `clap 3.0` \o/ in the near future
- man pages
- Best practices on error handling
- Katharina:
- clap 3.0 & man pages
- cargo install: custom hooks, e.g. for additional artifacts; rework idea from old RFC as "cargo dist"
- Pascal
- Bad idea on his part to reservese the order
- Main idea: have a larger scope of people and problems
- Katharina: To what extent do we want to focus on CLIs or expand to be an "Application WG"?
- Pascal: Do we want to search for problem spaces or work on our own problem space only?
- Matthias: Error handling is relevant to lots of things
- Daniel: concearn about expanding scope to GUIs because there's just a lot to be done there
- Pascal: if we expand the working group definition, would we risk the group become too big?
- General idea: stick to CLI stuff, but be open to create new working groups/ teams that handle specific subjects like "error handling" and "packaging".
- Who is a member of the team?
- Either: everybody who makes a CLI or everyone who helps maintain CLI-WG stuff
- Finding consensus is harder with a larger, fluid group
## Pascal's summary 2019-11-18
- Current WG members want to continue! Yay!
- Refocus on being a group of CLI app authors who want to help each other
- Group's job is to curate: Have a good grasp on the ecosystem, highlight cool projects, but also open issues
- This is a continous process, so it's okay for people to come and go
- Is "working group" still a good name? We kinda want to stay in "Rust lingo". The above also fits a "shepards" team like dev tools.
- Long discussion about where to have conversations
- Desire for a longer term, searchable medium
- Discord is low-volume right now, but also ephemeral. Github issues not well suited for questions.
- Mailing lists are apparently cool again (But a discourse category might also work)
- Check-in meetings
- we failed to do this in a good way so far
- synchronous, Pascal proposes video calls
- regular, e.g. every first Monday at 8pm UTC
- could be open to anyone, but ideally with a semi-rigid structure (e.g., collect topics in a document beforehand, every topic gets 2min)
## The Core Team Questionnaire
* What are some of the things the working group has done that you feel have worked very well?
* Pascal: In general, making a very good case for writing CLIs in Rust.
* Pascal: The CLI books seems to be popular among the people who manage to find it :)
* Pascal: We've managed to curate a list of issues in the ecosystem that we can probably spend a few more years on to fix
* What are some of the things that have not worked so well?
* Pascal: We tried to implement a lot of stuff ourself while overestimating how much time we have.
* Pascal: I have not managed to establish structured meetings.
* If you could do it again, what would you do differently?
* Pascal: Focus on having regular discussions with people currently writing CLI apps and see what issues they needed to solve, instead of trying to preempt that by fixing them ourselves :)
* What could the Rust org have done to help working groups?
* Pascal: Not sure. There was little expected structure that I percieved. One aspect that I now realized was missing was a hard "expiration date", even though the working groups were meant to be temporary.
* Did the Rust org do anything that felt harmful, rather than helpful, to working groups?
* Pascal: Not that I recall.
## Niko's email
> Dear working group,
>
> Hi! I'm writing from the core team. As we head into the end of 2019, we were thinking it would be good to do a "check in" on the state of the domain working groups. We are wondering in particular whether the "working group" format is still a good match.
>
> As a review (and to make sure we all understand the history the same way), the domain working groups were created in the Rust 2018 Roadmap as a way for people to explore and uncover the needs of specific domains. They didn't have a completely clear set of goals, nor timeline, so we want to checkin and see how you're feeling.
>
> To that end, we have a few questions for you.
>
> * What are some of the things the working group has done that you feel have worked very well?
> * What are some of the things that have not worked so well?
> * If you could do it again, what would you do differently?
> * What could the Rust org have done to help working groups?
> * Did the Rust org do anything that felt harmful, rather than helpful, to working groups?
> * At this point, do you feel the working group is still active?
> * Is the "working group" designation still a good fit?
> * If not, what do you think would be better?
> * (At the extreme ends, for example, it might make sense to disband, or perhaps to create a full-fledged Rust team.)
>
> Thanks!
>
> regards,
> Niko, on behalf of the core team
## Pascal's initial Email
> Hey folks,
>
> As you might have seen, the Rust project is currently planning the roadmap for the next year. This includes reviewing how the teams and working groups are doing, and what they want to do in the future. This includes the CLI WG!
>
> I first of all want to take this opportunity to apologize for the lack of… everything in the last few months. I said I'd try to invest more time in the WG and schedule regular meetings, and I failed. I'm sorry. At the same time I'm very grateful for people like Dylan and Ed who continued working on the WG topics and also helped a bunch of people in discord channel! You're awesome!
>
> This is the present. Now, let's look at the future. What do you envision the CLI WG to be/do next year? To get a discussion started, I'd to present a few quite different but possible options:
>
> 1. We could *continue* with the same process as next year: Make a new roadmap of topics to focus on (and/or finish what we did this year), and be the team to help implement them.
>
> 2. We could *reinvent* the working group as a "CLI authors group" where we don't focus on finishing projects under an umbrella working group, but instead focus on being a forum trying to help out people trying to write CLIs in Rust. This would loosen the meaning on membership in the WG to barely have any meaning at all. The focus of the working group could be highlighting cool CLI projects and pointing out issues in the ecosystem by publishing a newsletter and continuing the active twitter account.
>
> 3. We could *expand* the WG to be similar to the core dev tools team: We act as shepherds of projects relevant to the CLI ecosystem. This would mean that maintainers of these projects are de-facto members of the working group. The main focus would be to act like a committee that actively looks for holes in the ecosystem and gets involved in filling them.
>
> I'm really interested in what you think. Feel free to reply to this email, or reach out to me directly. If you think I forgot to include someone who might be interested in this, let me know, of forward this email to them directly.
>
> My idea was that it'd be good to discuss this asynchronously for a bit and get some ideas flowing, and then have a synchronous meeting.
>
> Thanks for reading this wall of text!
>
> --Pascal
## Notes from RustFest
Dylan, Pascal, and Katarina sat down at the impl days at RustFest to talk about how we could evolve the CLI working group in the future.
We were all pretty happy with the idea of expanding the scope and amount of people who are involved in the group.
We talked about:
- Regarding "expanding the scope", we talked about the format the group could take.
- We think it's a good idea to switch away from having a semi-defined group of "members" who work on crates/topics from a roadmap.
- Instead, we consider that becoming a group of "CLI ecosystem stakeholders" was more appropriate. (This is the third option mentioned in Pascal's email from last week.)
- People who are contributing to crates related to the CLI ecosystem are thus welcome to join the "CLI WG"
- this might actually also mean we should change the name away from "working group" as we are more of a "shepards team"?
- We could emphasise "terminals" as a medium, instead of just CLIs. We could expand the definition of the meaning to also involve TUIs
- this change should be announced publically on the (Internal) Rust blog; and we should reach out to people who qualify
- Have an async communcation channel, where people could ask questions and post announcements related to the CLI ecosystem
- less ephemeral than #cli-wg on discord
- we discussed the medium we wanted for a while, like mailing lists with public archives and a category on the users' discourse were options mentioned.
- Have synchronous meetings (e.g. video calls) to check in on the projects whose maintainers make up our group
- regular: pick a recurring time like "every first Monday at 8pm UTC"
- Agenda can be in the shape of going through all projects and asking "what's been going on in the last month?"
- Make sure at the end we added reports from the projects in the agenda, so it can be published for people who want to see what we are doing
- Find common topics across projects
- There are two special roles, meeting facilitators, and core team contacts
- These can be the same people
- Co-leads in different time zones might be good