├── .editorconfig ├── .github └── settings.yml ├── .gitignore ├── CODE_OF_CONDUCT.md ├── LICENSE ├── README.md ├── logs ├── 2018-02-20-cli-wg-initial-meeting.log ├── 2018-03-09-cli-wg-meeting.log ├── 2018-03-23-third-meeting.log ├── 2018-05-03-packaging.log └── 2018-05-03-packaging.md └── survey-results ├── Readme.md ├── crates.svg ├── gaps.svg ├── languages.svg ├── packaging.svg ├── platforms.svg ├── rust-user-since.svg ├── what-to-improve.svg └── why-rust.svg /.editorconfig: -------------------------------------------------------------------------------- 1 | # EditorConfig helps developers define and maintain consistent 2 | # coding styles between different editors and IDEs 3 | # editorconfig.org 4 | 5 | root = true 6 | 7 | 8 | [*] 9 | end_of_line = lf 10 | charset = utf-8 11 | trim_trailing_whitespace = true 12 | insert_final_newline = true 13 | indent_style = space 14 | indent_size = 4 15 | 16 | [*.rs] 17 | indent_style = space 18 | indent_size = 4 19 | 20 | [*.toml] 21 | indent_style = space 22 | indent_size = 4 23 | 24 | [*.md] 25 | trim_trailing_whitespace = false 26 | -------------------------------------------------------------------------------- /.github/settings.yml: -------------------------------------------------------------------------------- 1 | # These settings are synced to GitHub by https://probot.github.io/apps/settings/ 2 | 3 | repository: 4 | description: CLI working group 5 | homepage: "https://rust-cli.github.io/book" 6 | topics: rust cli command-line 7 | has_issues: true 8 | has_projects: false 9 | has_wiki: false 10 | has_downloads: false 11 | default_branch: master 12 | 13 | allow_squash_merge: true 14 | allow_merge_commit: true 15 | allow_rebase_merge: true 16 | 17 | allow_auto_merge: true 18 | delete_branch_on_merge: true 19 | 20 | labels: 21 | - name: "A-argparse" 22 | description: "Area: Argument parsing" 23 | color: '#f7e101' 24 | - name: "A-ergonomics" 25 | description: "Area: Ease of solving CLI related problems (e.g. filesystem interactions)" 26 | color: '#f7e101' 27 | - name: "A-styling" 28 | description: "Area: Terminal output styling" 29 | color: '#f7e101' 30 | - name: "A-interaction" 31 | description: "Area: Interactive terminal (prompts, progress bars)" 32 | color: '#f7e101' 33 | - name: "A-tui" 34 | description: "Area: TUI (full control of terminal)" 35 | color: '#f7e101' 36 | - name: "A-diagnostic" 37 | description: "Area: Program diagnostics (errors, panics, logging, etc)" 38 | color: '#f7e101' 39 | - name: "A-config" 40 | description: "Area: Configuration management" 41 | color: '#f7e101' 42 | - name: "A-testing-cli" 43 | description: "Area: One-shot testing of CLIs (no interaction)" 44 | color: '#f7e101' 45 | - name: "A-testing-tui" 46 | description: "Area: Testing of time and user dependent CLIs" 47 | color: '#f7e101' 48 | - name: "A-doc" 49 | description: "Area: Documenting your CLI (e.g. man pages)" 50 | color: '#f7e101' 51 | - name: "A-distribution" 52 | description: "Area: Licensing, packaging, etc" 53 | color: '#f7e101' 54 | - name: "A-book" 55 | description: "Area: Documenting how to create CLIs" 56 | color: '#f7e101' 57 | - name: "C-tracking-issue" 58 | description: "Category: A tracking issue for an unstable feature" 59 | color: '#f5f1fd' 60 | - name: "E-help-wanted" 61 | description: "Call for participation: Help is requested to fix this issue." 62 | color: '#02E10C' 63 | 64 | branches: 65 | - name: master 66 | protection: 67 | required_pull_request_reviews: null 68 | required_conversation_resolution: true 69 | enforce_admins: false 70 | restrictions: null 71 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | book 2 | target 3 | -------------------------------------------------------------------------------- /CODE_OF_CONDUCT.md: -------------------------------------------------------------------------------- 1 | # The Rust Code of Conduct 2 | 3 | A version of this document [can be found online](https://www.rust-lang.org/conduct.html). 4 | 5 | ## Conduct 6 | 7 | **Contact**: [rust-mods@rust-lang.org](mailto:rust-mods@rust-lang.org) 8 | 9 | * We are committed to providing a friendly, safe and welcoming environment for all, regardless of level of experience, gender identity and expression, sexual orientation, disability, personal appearance, body size, race, ethnicity, age, religion, nationality, or other similar characteristic. 10 | * On IRC, please avoid using overtly sexual nicknames or other nicknames that might detract from a friendly, safe and welcoming environment for all. 11 | * Please be kind and courteous. There's no need to be mean or rude. 12 | * Respect that people have differences of opinion and that every design or implementation choice carries a trade-off and numerous costs. There is seldom a right answer. 13 | * Please keep unstructured critique to a minimum. If you have solid ideas you want to experiment with, make a fork and see how it works. 14 | * We will exclude you from interaction if you insult, demean or harass anyone. That is not welcome behaviour. We interpret the term "harassment" as including the definition in the Citizen Code of Conduct; if you have any lack of clarity about what might be included in that concept, please read their definition. In particular, we don't tolerate behavior that excludes people in socially marginalized groups. 15 | * Private harassment is also unacceptable. No matter who you are, if you feel you have been or are being harassed or made uncomfortable by a community member, please contact one of the channel ops or any of the [Rust moderation team][mod_team] immediately. Whether you're a regular contributor or a newcomer, we care about making this community a safe place for you and we've got your back. 16 | * Likewise any spamming, trolling, flaming, baiting or other attention-stealing behaviour is not welcome. 17 | 18 | ## Moderation 19 | 20 | 21 | These are the policies for upholding our community's standards of conduct. If you feel that a thread needs moderation, please contact the [Rust moderation team][mod_team]. 22 | 23 | 1. Remarks that violate the Rust standards of conduct, including hateful, hurtful, oppressive, or exclusionary remarks, are not allowed. (Cursing is allowed, but never targeting another user, and never in a hateful manner.) 24 | 2. Remarks that moderators find inappropriate, whether listed in the code of conduct or not, are also not allowed. 25 | 3. Moderators will first respond to such remarks with a warning. 26 | 4. If the warning is unheeded, the user will be "kicked," i.e., kicked out of the communication channel to cool off. 27 | 5. If the user comes back and continues to make trouble, they will be banned, i.e., indefinitely excluded. 28 | 6. Moderators may choose at their discretion to un-ban the user if it was a first offense and they offer the offended party a genuine apology. 29 | 7. If a moderator bans someone and you think it was unjustified, please take it up with that moderator, or with a different moderator, **in private**. Complaints about bans in-channel are not allowed. 30 | 8. Moderators are held to a higher standard than other community members. If a moderator creates an inappropriate situation, they should expect less leeway than others. 31 | 32 | In the Rust community we strive to go the extra step to look out for each other. Don't just aim to be technically unimpeachable, try to be your best self. In particular, avoid flirting with offensive or sensitive issues, particularly if they're off-topic; this all too often leads to unnecessary fights, hurt feelings, and damaged trust; worse, it can drive people away from the community entirely. 33 | 34 | And if someone takes issue with something you said or did, resist the urge to be defensive. Just stop doing what it was they complained about and apologize. Even if you feel you were misinterpreted or unfairly accused, chances are good there was something you could've communicated better — remember that it's your responsibility to make your fellow Rustaceans comfortable. Everyone wants to get along and we are all here first and foremost because we want to talk about cool technology. You will find that people will be eager to assume good intent and forgive as long as you earn their trust. 35 | 36 | The enforcement policies listed above apply to all official Rust venues; including official IRC channels (#rust, #rust-internals, #rust-tools, #rust-libs, #rustc, #rust-beginners, #rust-docs, #rust-community, #rust-lang, and #cargo); GitHub repositories under rust-lang, rust-lang-nursery, and rust-lang-deprecated; and all forums under rust-lang.org (users.rust-lang.org, internals.rust-lang.org). For other projects adopting the Rust Code of Conduct, please contact the maintainers of those projects for enforcement. If you wish to use this code of conduct for your own project, consider explicitly mentioning your moderation policy or making a copy with your own moderation policy so as to avoid confusion. 37 | 38 | *Adapted from the [Node.js Policy on Trolling](http://blog.izs.me/post/30036893703/policy-on-trolling) as well as the [Contributor Covenant v1.3.0](https://www.contributor-covenant.org/version/1/3/0/).* 39 | 40 | [mod_team]: https://www.rust-lang.org/team.html#Moderation-team -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | MIT License 2 | 3 | Copyright (c) 2018 rust-lang-nursery 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 21 | SOFTWARE. 22 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # CLI working group 2 | 3 | This repo is for coordinating the work of the Rust CLI Working Group, 4 | also known as "Rust CLIQuE" (Rust CLI Quality Enhancement). 5 | 6 | - [Working groups?](https://internals.rust-lang.org/t/announcing-the-2018-domain-working-groups/6737) 7 | - [Announcement of this WG](https://internals.rust-lang.org/t/announcing-the-cli-working-group/6872/1) 8 | - Chat with us on [Zulip](https://rust-lang.zulipchat.com/#narrow/stream/220302-wg-cli) 9 | 10 | 11 | ## Vision 12 | 13 | Let's make this a true statement: 14 | 15 | Rust makes writing crossplatform, tested, modern command line applications frictionless 16 | while incorporating industry best practices and providing great documentation. 17 | 18 | ## Role of WG-CLI 19 | 20 | - Identify gaps between here and the vision 21 | - Mentoring people working to fill the gaps 22 | - Keeping the lights on for core CLI crates 23 | - Venue for CLI authors to collaborate 24 | 25 | ## Focus Areas 26 | 27 | - [Argument parsing](https://github.com/rust-cli/team/labels/A-argparse) 28 | - [argpaerse-rosetta-rs](https://github.com/rosetta-rs/argparse-rosetta-rs) 29 | - [Ease of solving CLI related problems (e.g. filesystem interactions)](https://github.com/rust-cli/team/labels/A-ergonomics) 30 | - [Terminal output styling](https://github.com/rust-cli/team/labels/A-styling) 31 | - [Interactive terminal (prompts, progress bars)](https://github.com/rust-cli/team/labels/A-interaction) 32 | - [TUI (full control of terminal)](https://github.com/rust-cli/team/labels/A-tui) 33 | - [Program diagnostics (errors, panics, logging, etc)](https://github.com/rust-cli/team/labels/A-diagnostic) 34 | - [Configuration management](https://github.com/rust-cli/team/labels/A-config) 35 | - [One-shot testing of CLIs (no interaction)](https://github.com/rust-cli/team/labels/A-testing-cli) 36 | - [assert_cmd](https://github.com/assert-rs/assert_cmd) / [assert_fs](https://github.com/assert-rs/assert_fs) 37 | - [snapbox](https://github.com/assert-rs/trycmd/tree/main/crates/snapbox) 38 | - [trycmd](https://github.com/assert-rs/trycmd/) 39 | - [Testing of time and user dependent CLIs](https://github.com/rust-cli/team/labels/A-testing-tui) 40 | - [Documenting your CLI (e.g. man pages)](https://github.com/rust-cli/team/labels/A-doc) 41 | - [Licensing, packaging, etc](https://github.com/rust-cli/team/labels/A-distribution) 42 | - [Documenting how to create CLIs](https://github.com/rust-cli/team/labels/A-book) 43 | - [book](https://github.com/rust-cli/book) 44 | 45 | While most of these cross-domains with GUIs, web backends, etc, they are also commonly in the critical path a CLI and so in-scope. 46 | -------------------------------------------------------------------------------- /logs/2018-02-20-cli-wg-initial-meeting.log: -------------------------------------------------------------------------------- 1 | 18:00 hey @/all, welcome to the first CLI working group meeting! 2 | 18:00 This meeting about the goals and format of the working group 3 | 18:00 It is not about concrete details, I want to keep it focused on big picture for now 4 | 18:01 The time box is an hour (let's see if I manage to keep us on schedule) 5 | ... 6 | 18:02 first of all, thank you all for showing up! 7 | 18:02 and for discussion so much stuff already! 8 | ... 9 | 18:02 if you haven't seen it yet, the etherpad is packed with cool ideas: https://public.etherpad-mozilla.org/p/rust-cli-wg 10 | 18:04 i want to go through the "goals" for a bit 11 | 18:04 > - Rust is known to be a very good language for writing CLI tools 12 | 18:04 > - "Writing a CLI tool" is a good way to get started with Rust as a beginner 13 | 18:04 > - Make it easy to ship well-tested binaries 14 | 18:04 > - "Writing seamless binaries in Rust should be effortless" 15 | 18:04 does anyone want to add something to that list? 16 | 18:04 or, even better, want to compress some of the points into a new one? :) 17 | 18:05 how about "work effectively the same on all platforms"? 18 | 18:05 i think it's important to have a good slogan and something we can use when deciding what to do and what not to focus on 19 | 18:05 Agreed. 20 | 18:06 @Dylan-DPC you mean like "i'm sure my rust cli app works on a mac even though i haven't tested it"? 21 | 18:06 yeh 22 | 18:07 as in the user doesn't have to bother about different platforms 23 | 18:07 that's a pretty cool goal! 24 | 18:07 cool. that's really ambitious, though! 25 | 18:07 Seems like some of the high level ideas 26 | 18:07 - Fun / low friction 27 | 18:07 - Cross-platform 28 | 18:07 - End-user consumable (distribution) 29 | 18:07 - Releasing with confidence 30 | 18:08 Now how to capture that in a slogan :) 31 | 18:08 agreed. platform compatibility is a great goal 32 | ... 33 | 18:08 that's a pretty good summary ^ 34 | 18:08 Very ambitious though 35 | 18:08 great summary! 36 | 18:08 i like @yoshuawuyts' "Writing seamless binaries in Rust should be effortless" as a base but like to make it a bit more concrete 37 | 18:08 @epage probably would add to that "Should feel native to the platform" 38 | ... 39 | 18:09 Like file locations for config files are different on each platform, coloring is different (I think we have some abstraction around that already) 40 | 18:09 I'd say the things that are nonobvious so far are 1) how to develop a test harness for a CLI tool and 2) how to structure error handling 41 | 18:09 ..., file path handling 42 | 18:09 there are a few Windows gotchas as well 43 | ... 44 | 18:10 these all sounds like very concrete things we could work on! 45 | ... 46 | 18:12 @killercup yeah, I like having that slogan as a base - and then expand with the list of @epage for more detail :D 47 | 18:12 so, i'm trying to come up with a sentence that covers this, something like "frictionless" and with "known best practices" 48 | ... 49 | 18:13 @yoshuawuyts to be clear, my list was created to help us brainstorm parts to include in the slogan 50 | 18:13 gotcha! 51 | 18:14 killercup: sounds like "doing the right thing for reach platform should be straight forward" or something 52 | 18:14 "Frictionlessly creating CLIs with industry best practices"? 53 | 18:14 but then, nicer 54 | 18:15 "Writing CLI apps in Rust is a frictionless experience with known best practices that work across platforms, good documentation, and effortless distribution" 55 | 18:15 maybe a bit shorter :D 56 | 18:15 Those last to fall under frictionless to me 57 | 18:15 [edit] maybe make it a bit shorter :D 58 | 18:16 "writing cross-platform frictionless apps" 59 | 18:16 > "Frictionlessly creating CLIs with industry best practices”? 60 | 18:16 “Frictionlessly creating world class CLIs" 61 | 18:16 [edit] > "Frictionlessly creating CLIs with industry best practices”? 62 | 18:16 [edit] “Frictionlessly creating world class CLIs" 63 | 18:16 "frictionless" is meant to describe the process, not the app 64 | 18:16 fair point 65 | 18:16 @epage yeah, i wanted to specify what is frictionless about it 66 | 18:17 don't mind having @killercup's version as a "working title" - can always revisit later 67 | 18:17 "Rust makes best-practice CLI applications frictionless through crates and documentation"? 68 | 18:17 i think we're on the same page, i'll paste the suggested ones in the etherpad and we can decide later on 69 | ... 70 | 18:18 cool, so, next point 71 | 19:18 what areas need out focus? 72 | 18:19 like, there are a lot of efforts to make writing CLI apps easier 73 | 18:19 where do we need to help out? 74 | 18:19 File management (cross platform stuff) 75 | 18:19 Especially for config files that would be great 76 | 18:19 @Eijebong like, dealing with paths or dealing with config files? 77 | 18:20 For linux under ~/.config, under Mac ~/Library (I think?), Windows…no idea 78 | 18:20 app packaging 79 | 18:20 is there any plan to make one crate that others can use and extend? 80 | 18:20 conglomeration crates / ecosystem discovery / API uniformity 81 | 18:20 maybe we should define CLI tools before 82 | 18:20 If I need a config file, I don't want to know that it should be `${XDG_CONFIG:${XDG_HOME}/.config:/home/${user}/.config` on linux, `%AppDir%/App/` on windows and something else on osx (paths are probably all wrong :D) 83 | 18:20 `~/.config`, `~/.local`, `~/.cache` 84 | 18:21 @yoshuawuyts Plz respect `${XDG_*}`stuff :o 85 | 18:21 @TeXitoi Fair point, would a (n)curses tui count as a CLI? 86 | 18:21 @TeXitoi ah good point, how'd you define it? 87 | ... 88 | 18:22 there is a crate for "determing system configuration" and it's apparently not as easy as it sounds 89 | 18:22 I'd define as a program that is launch in a terminal with parameter, no user interaction during the execution, and that do work on files, network and/or output to terminal 90 | 18:22 So speaking of where the files are, the app_dirs crate exists. Is it a discovery issue, maturity issue, or something else? 91 | 18:22 but it is definitely something that should be solved 92 | 18:22 (thus ncurses is not in my definition) 93 | 18:22 @epage that's the one! 94 | 18:23 this one? https://github.com/AndyBarron/app-dirs-rs 95 | 18:23 it hasn't had an update and I heard from @BurntSushi that it is not maintained 96 | 18:23 (neither is daemons) 97 | 18:23 @TeXitoi good definition, and i think it's fair to start with this 98 | 18:25 (config files may or may not enter in my definition) 99 | 18:25 okay, so we have 100 | 18:25 101 | 18:25 - dealing with configs 102 | 18:25 - packaging 103 | 18:25 - crate discovery 104 | 18:25 - testing cli apps (@dherman mentioned this earlier) 105 | 18:25 - error handling and user facing output 106 | 18:26 So I am obviously biased, but one area that we have been struggling with in `fd` is the handling of file paths across platforms 107 | 18:26 How so? 108 | 18:26 Things like: absolute paths on Windows (UNC prefixes) 109 | 18:26 or: UTF-8 filenames on MacOS (the filesystem normalizes UTF-8 strings) 110 | 18:27 @TeXitoi 111 | 18:27 > I'd define as a program that is launch in a terminal with parameter, no user interaction during the execution, and that do work on files, network and/or output to terminal 112 | 18:27 I'd like to ammend this to: launch in a terminal with configuration [cmd-args, ENV, config-files], runs to completion with no/minimal user interaction and does work on files, network and/or std{in,out,err} 113 | 18:27 one common theme i sense here is that there are some efforts (a.k.a. crates) but there are no solutions that solve enough of the issues 114 | 18:27 @sharkdp I had to create a little half-baked crate for turning a regular path into a verbatim path -- feels like a more polished crate waiting to happen 115 | 18:27 @sharkdp fd? 116 | 18:27 @sharkdp https://github.com/notion-cli/notion/blob/master/crates/verbatim/src/lib.rs 117 | 18:27 @sharkdp https://crates.io/crates/abs_path look like what you want? 118 | 18:28 @TeXitoi https://github.com/sharkdp/fd 119 | 18:29 @sharkdp thanks 120 | 18:29 @killercup more important, all solutions are disjointed. There is no unified API or even an understanding of where the holes are most of the time 121 | 18:29 so is our main priority to build a master crate here? or fix existing issues everywhere? 122 | 18:30 @vitiral that's what we're here to do: create a good end-to-end story :) 123 | 18:30 @Dylan-DPC this is a _team_, so I think the solution will be to experiment with lots of approaches -- but try to unify efforts as much as possible 124 | 18:30 @Dylan-DPC It could probably be a mix of the two approaches. With good documentation where to find what 125 | 18:30 that brings us to the next point on my agenda that also let's me answer @Dylan-DPC question! 126 | ... 127 | 18:30 how should we fix this? 128 | 18:31 (the "### How to get there" part of the etherpad) 129 | 18:31 @vitiral i know but my question was like "what should we focus more on". 130 | 18:31 probably part code, part guides, right? 131 | 18:32 i think a nice approach is trying to write an "ideal guide" 132 | 18:32 Part code, part guides, part tools to make life easier 133 | 18:32 to see where the holes are 134 | 18:32 That works 135 | 18:32 what do you mean by an "ideal guide"? 136 | 18:32 about focus - I think addressing universal issues would be a good start 137 | 18:33 issues that affect majority of CLI tools 138 | 18:33 yeah i agree 139 | 18:33 @yoshuawuyts you write a guide that describes what writing a CLI app in rust is like _in the future_, and then see where it doesn't yet work in the present 140 | 18:33 Kind of like steve's 2018 blog post 141 | 18:33 cool! 142 | 18:33 The basic problem, from a newbie's perspective, is that these tools are disjointed. Rust's `stdlib` is small, but there is no "extended stdlib". It would be great (IMO) if someone could say "gosh, one of the worst things about rust is that the stdlib is so small" and people would reply "then use CRATEX" (I'm biased, as I have started the [ergo ecosystem](https://github.com/rust-crates/ergo) to solve this problem) 143 | 18:34 @killercup That sounds like a great idea 144 | 18:34 @vitiral that's one solution, but another might be "click on 'CLI apps' on rust-lang.org" and it has a guide that starts with `cargo new --template rust-lang/cli` 145 | 18:34 yeah 146 | 18:35 I'm not sure we necessarily need an extended standard library, as there are great crates for a lot of things already (clap, termcolor, etc.) 147 | 18:35 @killercup where it downloads an "official" template of some kind from crates.io? 148 | 18:36 @vitiral exactly, and that templates already contains a bunch of `extern crate foo;` and a good readme and ci setup for example 149 | 18:36 or we could create a crate so anyone working on CLIs can use the crate as a base crate. The only issue being that existing crates might have to rewrite some stuff 150 | 18:36 @sharkdp just to be clear, the "extended standard library" is just a conglomeration of those great crates. It's goals are to reduce boilerplate and unify the api+docs 151 | ... 152 | 18:36 @killercup I like the idea of "official templates" regardless of other decisions :thumbsup: 153 | ... 154 | 18:37 `cargo new --template cli` and `ergo` aren't mutually exclusive either :D 155 | ... 156 | 18:37 maybe they could be distributed via rustup/cargo directly? 157 | 18:37 and you could also provide a github url or something? 158 | 18:38 let's not talk about the details for now, and the cargo folks probably already have some plans 159 | 18:38 okay, good point 160 | 18:38 Crate-wise, I think the thing that could be valuable is to expand on an idea I've seen floated from time to time, creating higher level abstractions over the existing libs. For example, `std::path` is pretty low level when you compare it to `pathlib` in Python. If we provide some higher level libs (at the cost of performance or lack of platform neutrality) that'd be a big help for people. They could then progress to the lower level stuff in inner 161 | 18:38 loops 162 | ... 163 | 18:39 @epage +1 ya but i guess we need to provide some customisability as well 164 | 18:39 except it shouldn't lack platform neutrality 165 | 18:39 Well, @vitiral , we have already been talking about it :) 166 | 18:39 @epage yep, that's basically why i wrote quicli :) 167 | 18:39 process-wise we now need decide how do proceed 168 | 18:39 the reason why a lot of people start their own crates from scratch is because a certain base crate doesn't provide what you want 169 | 18:39 @epage (ssh... they don't have to know :laughing:) 170 | 18:39 What I meant by lack of platform neutrality is that it might make assumptions about the meaning of `.`, `..`, `//` which `std::path` doesn't do today but I think people expect 171 | 18:40 @vitiral isn’t the “high level abstractions” what `ergo` somehow aims to provide. right? 172 | 18:40 @mattgathu yes 173 | 18:40 Someone should probably kickstart the "ideal guide" I reckon? 174 | 18:40 [edit] @mattgathu yes (edit: that is one of its goals) 175 | 18:40 So what do we need to discuss about the ideal guide or how do we get organized into writing it? 176 | 18:41 uhmm let's cover the broader topics first 177 | 18:41 personally I think the cookbook is a great place to start. How would the cookbook look in a perfect world? 178 | 18:41 i think it'd make sense to have smaller groups of people "claim" problem spaces, and have this working group be more about orchestration 179 | ... 180 | 18:42 we have this repo: https://github.com/rust-lang-nursery/cli-wg 181 | 18:42 where i'll also post the logs of this meeting and the etherpad notes 182 | 18:42 @killercup do we have edit access/how should we open a repo, etc? 183 | ... 184 | 18:43 You are all welcome to have editor access on rust-crates (which is the owner of ergo) 185 | 18:43 https://github.com/rust-crates/ 186 | 18:43 great 187 | 18:43 we can make any repos we want. Or we can use a different organization 188 | 18:44 @killercup so is your thought that, say the guide group, would have a subfolder and start posting PRs of md files for it? 189 | 18:44 i'd like to use the cli-wg repo for orchestration of efforts, and maybe we can create rust-crates repos for individual implementations? 190 | 18:44 @epage for example, yeah 191 | 18:45 @killercup I just made you full admin on rust-crates. I've been meaning to and forgot 192 | 18:45 yeah that's why i was suggesting an organisation 193 | 18:45 @epage or just discuss stuff in issues 194 | 18:45 the idea is to have a single repo where we can track stuff we are working on 195 | 18:45 and also talk about integration issues, and common efforts 196 | 18:45 @vitiral thanks! 197 | 18:45 sounds reasonable 198 | 18:46 btw when getting to implementation, `crate-ci` is possible home for relevant tools (like packaging) 199 | 18:46 I agree -- `cli-wg` is a great place to document RFC's/discussions, open and discuss issues, keep notes of meetings and document our progress/efforts 200 | 18:47 the best case scenario is that we'll open a bunch of tracking issues, e.g. "How to do configuration management in CLI apps" and then over the next few months fill them with good discussions and links to PRs implementing stuff to get towards that ideal guide's future 201 | 18:48 it probably wouldn't be a bad idea to copy/paste the doodle as our first "roadmap" and open an issue to discuss it further 202 | 18:49 i'm also very certain we can't solve all the problems at once, so i'd like to settle on some, let's say 3, that we want to tackle _right now_ 203 | 18:49 well, not "right now" right now, but "next" 204 | 18:49 And the rest of the doodle could be split up into multiple parts that are somewhat related. Makes it less monolithic 205 | 18:50 [edit] i think you all mean "etherpad" and not "the thing to find dates for meetings" ;) 206 | ... 207 | 18:51 so, when there are some tracking issues/ideal guides open, let's try to put some momentum behind a few of them instead of everyone doing something only by themselves :) 208 | 18:52 we can divide it into milestones and address certain issues in each milestone (preferably a quarter of the year) 209 | 18:52 I don't have any projects myself so I'd love to contribute wherever needed :P 210 | ... 211 | 18:53 [edit] perfect! that conveniently brings us to the next point in my secret agenda for this meeting (that is totally not a post-it with "what, how, who, when")! 212 | 18:53 how should we do meetings? 213 | 18:53 like this? :P 214 | 18:54 that's one possibility, yeah 215 | 18:54 but more like, should we check in with each other every week? 216 | 18:54 biweekly? 217 | 18:54 Gitter is pretty convenient. Though if you stop reading for like 5 minutes it's super hard to catch up :joy: 218 | 18:54 yeah, think bi-weekly is a good one 219 | 18:54 haha true kat 220 | 18:54 Also, if we're breaking down into sub-groups, that'll help with catching up 221 | 18:54 every two weeks sounds good 222 | ... 223 | 18:55 sub groups could meet up every week 224 | 18:55 @epage :+1: Would we have different gitter channels then? 225 | 18:55 we can create rooms 226 | 18:55 Rooms seems reasonable. It'll make it easier to peek in on each other 227 | 18:55 @spacekookie feel free to create new ones, but i personally like how people lurking in a room can chime in and help ;) 228 | 18:56 As long as the meetings for the different groups aren't at the same time ;) 229 | 18:56 well you can be in 2 rooms at the same time ;) 230 | 18:57 Hello, I think rooms should only be created if the traffic warrants it, this isn't a very high volume channel so unless there is a lot of talking over. 231 | 18:57 aye, agree 232 | 18:57 @Aaronepower I agree, nothing is more depressing than sitting in an empty room :frowning: 233 | 18:57 [edit] Hello, I think rooms should only be created if the traffic warrants it, this isn't a very high volume channel so unless there is a lot of talking over it'd probably be easier to keep it to a single channel. 234 | ... 235 | 18:57 let's create new rooms lazily 236 | 18:58 if we discuss all the subgroups in one place then everyone will toe in with their comments and it will become one entire group instead of sub groups 237 | 18:58 @Dylan-DPC Is that a bad thing? 238 | 18:58 it isn't. but it kinda defeats the purpose of a subgroup 239 | 18:59 i think for the initial setup and writing guides it might also be helpful to use a non-text medium like video chat, because it's more personal and we can write a guide/speak at the same time :) 240 | 18:59 Dylan-DPC: we're 20 people, and it hasn't been a problem so far - creating rooms once it becomes a problem sounds like a good outcome (: 241 | ... 242 | 18:59 also multiple subgroups can't have a meeting at the same time unless they converge it into 1 243 | ... 244 | 19:00 [edit] @killercup so what's the plan next? 245 | 19:01 next up, we should all open issues on https://github.com/rust-lang-nursery/cli-wg ! 246 | ... 247 | 19:02 i'll send out a doodle (the meeting time decider thing!) for the next WG meeting in two about two weeks 248 | ... 249 | 19:03 1. Do we just open issues for the initial batch of jobs? 250 | 19:03 2. Does one person does it so we don't accidentally have two issues for one task? 251 | ... 252 | 19:06 I was about to open an issue for the config crate thingy but was waiting for someone else to open an issue so I have a template what to write :P 253 | 19:06 speaking of opening things on github: people alright if I PR the stuff we discussed here as a meeting note for today? 254 | ... 255 | 19:08 and with that, thank you @/all for the great meeting! it's not easy to find a format for this group, and settle on stuff to work on, but i'm confident we're on a good way! (and we can always improve our process once we have a couple things going!) 256 | 19:08 Correct me if I'm wrong, but I see this being a two part thing; part 1 we've already started which is *identify* areas we can *action*. Part 2 then becomes actioning those items. As far as action items go, there seems to be some common abstract ideas coming from here such as, "specific crate assistance" (i.e. an already existing crate can be helped, enhanced, etc.), "docs" (from crate docs, to how-tos, to blogs, etc.), and "new crates" (existing 257 | 19:08 gaps in the ecosystem where a new crate could come in) and each of those could be broken down as well. 258 | 19:09 I think breaking some of this into "bite sized chunks" could help us make more progress, especially since for many this is a side project 259 | ... 260 | 19:11 And like @killercup already said, *we* don't necessarily need to action these items ourselves (I mean, if we can it's awesome, but it's not a must), but what can really help is finding those items, maybe mentoring/guiding and informing the Rust community about them 261 | 19:11 exactly. i'll try to open one issue per area we want to work on. for each, we then decide the course of action (improve or create) as well as find maintainers (we, others) 262 | ... 263 | 19:13 the "ideal guide" thing will be a bit orthogonal to that, and I hope it'll work as a driver to create new issues/ideas to improve 264 | ... 265 | -------------------------------------------------------------------------------- /logs/2018-03-09-cli-wg-meeting.log: -------------------------------------------------------------------------------- 1 | 18:00 # meeting time, @/all! 2 | 18:00 first up, [what are we doing?](https://github.com/rust-lang-nursery/cli-wg/issues?q=is%3Aissue+is%3Aopen+label%3A%22tracking+issue%22) 3 | 18:01 last meeting, we've talked about a bunch of topics and afterwards opened a bunch of issues 4 | 18:01 before getting into opening some more, let's take a minute to talk about the ongoing discussions 5 | 18:01 First off for me would be thank you for herding the cats and getting the readme up! 6 | 18:02 @epage thanks! is anyone against merging https://github.com/rust-lang-nursery/cli-wg/pull/17 ? 7 | 18:03 nothing's set in stone, but i think we've converged on the major points in these issues 8 | 18:04 (i'll merge it after the meeting/tonight unless someone objects) 9 | 18:04 I think it is appropriate. And having the option to include TUIs in the scope later (that's how I understand the statement at the bottom of the file) is nice. 10 | 18:04 Personally, I'd prefer a shorter, easier to process description of a CLI *but* seeing the sausage made, I realize its hard to do 11 | 18:05 cool 12 | 18:06 alright 13 | 18:07 the biggest issues by number of comments are config files (), colors (), and distribution () 14 | 18:08 would you say these are also the areas where we can find actionable stuff to do for the next 2-3 weeks? 15 | 18:08 is colors a big issue right now? i mean we can work on it but i don't think colors isn't going to be a blocker for someone releasing a cool CLI :P 16 | 18:08 true 17 | 18:08 :+1: 18 | 18:08 but the issue might be "what colors crate to use" ;) 19 | 18:09 yes, there are several options from what I know. Would be nice to have one "standard" here with a easy and nice API. 20 | 18:09 [edit] is colors a big issue right now? i mean we can work on it but i don't think colors is going to be a blocker for someone releasing a cool CLI :P 21 | 18:11 Searching for "color" in crates.io gives 250 results, searching "color" and "cli" gives 24. Not all of them are for this use-case, but having to select one gets harder the more options there are. 22 | 18:11 absolutely, and ideally one that follows best practices and is cross platform so you just don't have to think about it 23 | 18:11 How do we even want to handle the conversations? Would it help to have someone directing the conversation and summarizing it in the top issue? Should we be created WG RFCs? 24 | 18:12 for example, the config one has gotten pretty long at this point 25 | 18:12 and for distribution, it seems like "what is the role of cargo" needs its own thread. 26 | 18:12 :+1: 27 | 18:13 @epage an RFC works if you have a spec… i'm not sure that works best for our issues 28 | 18:13 [edit] @epage an RFC works if you have/want to write a spec… i'm not sure that works best for our issues 29 | 18:14 btw I'd be willing to facilitate the packaging discussion since I already have a goal of seeing that improve. 30 | 18:14 btw, the config issue has already resulted in a bunch of activity on https://github.com/soc/directories-rs 31 | 18:14 killercup: yay! 32 | 18:15 Nice! 33 | 18:16 @epage do you want to open more specific issues? if yes, which ones? :D 34 | 18:16 (re distribution) 35 | 18:17 if there are any dicussions going on in other crates we can add them to #14 36 | 18:17 :+1: 37 | 18:19 @killercup I'm on mobile, and can give a more detailed first thoughts on the survey later, but what jumps out to me is this: 38 | 18:19 People want more examples, guides, and standardization 39 | 18:19 ya documentation & examples 40 | 18:19 Colors, config files, error handling seem to the biggest gaps 41 | 18:20 Packing is also a naojor concern 42 | 18:20 Major* 43 | 18:20 @kbknapp thanks for checking in! yeah, that's how i read the survey so far, too 44 | 18:20 Also the ergonomics of file/path handling is a big thing 45 | 18:21 Cannot :+1: that enough! 46 | 18:21 Are there any write-ins on the fie/path problems? 47 | 18:21 also, clap by far the #1 most referenced crate :) 48 | 18:21 I'll post a gist of my more detailed comments later today when I get to a computer and link it here 49 | 18:21 Thanks! 50 | 18:22 The combination of testing and filesystem access is not covered by any crate, from what I see. 51 | 18:22 @kbknapp awesome, thanks! 52 | 18:22 I think there's also some hidden gem crates in the cli space I wasn't tracking 53 | 18:22 ya that's where we have to chip in @matthiasbeyer 54 | 18:22 testing + fs, is that different from https://docs.rs/dir-diff/0.2.0/dir_diff/ ? 55 | 18:22 @matthiasbeyer good to know its something already on my radar. 56 | 18:23 Might be nice to call some of those out and speak to "finding quality crates" issue 57 | 18:23 dir-diff is very limited. It only gives a boolean pass/fail 58 | 18:23 It doesn't let you check for more specific files, set of filesystem test fixtures, etc 59 | 18:23 @kbknapp i have a good/useful aggregation of referenced crates, remind me to send it to you :) 60 | 18:23 epage: ah yeah, gotcha 61 | 18:23 Well, I have to revoke my statement a bit: There's the "filesystem" crate and the "rsfs" crate which seem to try to implement a mock of the filesystem and operations so that one can do tests on an "inmemory filesystem" 62 | 18:24 If you look at the survey in Google sheets view see the second tab 63 | 18:24 When I searched last time there was no valueable option, so I implemented my own for this (in imag) 64 | 18:24 @matthiasbeyer can you comment on https://github.com/rust-lang-nursery/cli-wg/issues/9 ? 65 | 18:24 I'm always hesitant about mocking the file system. Either test directly against if or crate a trait for an abstraction just above the file system. 66 | 18:25 @epage and i talked a bit about assert_cli plans, maybe we can write down a plan over the next week 67 | 18:25 [Github] matthiasbeyer commented in rust-lang-nursery/cli-wg on issue: Testing CLI apps https://github.com/rust-lang-nursery/cli-wg/issues/9#issuecomment-371881945 68 | 18:25 @killercup done. Going to expand the comment later 69 | 18:26 thanks! 70 | 18:26 @kbknapp any completely new things that you noticed in the survey results? 71 | 18:26 [Github] matthiasbeyer commented in rust-lang-nursery/cli-wg on issue: Testing CLI apps https://github.com/rust-lang-nursery/cli-wg/issues/9#issuecomment-371881945 72 | 18:27 > Security credential handling. I wrote the 'credentials' crate to work with Hashicorp vault and/or environment variables. 73 | 18:28 @Dylan-DPC interesting! seems specific to Vault, though 74 | 18:28 yeh 75 | 18:29 @killercup I think so, but it's in my extended notes :P I can't remember off the top of my head 76 | 18:29 [Github] epage commented in rust-lang-nursery/cli-wg on issue: Testing CLI apps https://github.com/rust-lang-nursery/cli-wg/issues/9#issuecomment-371883157 77 | 18:30 @kbknapp no prob, we'll definitely talk about all of this again later :) 78 | 18:30 everything else fits into the config / colors / cross-platform boxes 79 | 18:30 let's get back to config file management for a sec 80 | 18:30 [edit] everything else fits into the config / colors / cross-platform / TUI boxes 81 | 18:31 is there anything uncontroversial we can just _do_ right now to make it better? 82 | 18:31 even if just experiment 83 | 18:31 [edit] even if just as an experiment 84 | 18:31 from the survey: 85 | 18:31 > A nice crate to handle multi-location config (global, user, project, cli/env). 86 | 18:31 Sorry, just got here :wave: 87 | 18:32 @Eijebong :wave: 88 | 18:32 What am I missing? From what I see all it needs is a serialization technique selected (json, toml, yaml via serde) plus a way to get the location of the file. So, all we need to address is the "location" part, isn't it? 89 | 18:32 @matthiasbeyer maybe? 90 | 18:33 is adding a file-storage thing to the configure crate a good idea right now? 91 | 18:33 or do we need something else? 92 | 18:33 A crate that *just* handles the where to store a global/user global config file is something we can do now...combinging it with format, , env, project, etc makes the scope too big 93 | 18:34 My auto-correct is a mess right now ;) 94 | 18:34 @kbknapp i think directories-rs gives us a system locations 95 | 18:34 Yes. And while we're at it: That crate should be able to hold "dummy" configuration files for testing. 96 | 18:34 Including cross platform "user global"? 97 | 18:35 I.e. `~/.conig` etc 98 | 18:35 @kbknapp haven't seen it but maybe 99 | 18:35 So its API should not give `PathBuf` but rather `R: Read`, IMHO. 100 | 18:35 Config* 101 | 18:36 okay, another questions: how about we write a config file adaptor for the configure crate and see how far we can go before it all breaks apart? :) 102 | 18:36 sounds fun :P 103 | 18:36 [Github] epage commented in rust-lang-nursery/cli-wg on issue: Config file management https://github.com/rust-lang-nursery/cli-wg/issues/7#issuecomment-371885056 104 | 18:37 and if yes, who's interested in doing that? (besides me) 105 | 18:37 :+1: 106 | 18:37 i'm in 107 | 18:38 awesome. i'll make a repo and add you and whoever else wants in :) 108 | 18:39 sounds good 109 | 18:40 great. next on the agenda: 110 | 18:41 ## do we want to form a "cli core team"? 111 | 18:41 What do you envision this core team would do? 112 | 18:41 basically organize and oversee the current efforts 113 | 18:42 Isn't that what the CLI WG already does? 114 | 18:42 or is there a difference between WG and Team? 115 | 18:42 but who is the "CLI WG"? :) 116 | 18:42 hm. true. 117 | 18:42 @killercup Anyone who participates ? 118 | 18:43 i'm just wondering if you want to have more defined "membership" or if it's fine as-is 119 | 18:43 i think it is better to split up in different sub-groups each of them tackling certain issues 120 | 18:43 I'm not against it but I think it's fine as is 121 | 18:43 cause once we start the actual work on the issues it will be a mess 122 | 18:44 right, that's a related thing: it'd be awesome to assign people to issues 123 | 18:45 e.g., @epage, you mentioned working distribution-things, can i assign you so people have someone to talk to? :) 124 | 18:45 Sure! 125 | 18:46 to do that i'll need to add you to a team that manages that repo ;) 126 | 18:47 @Dylan-DPC so, i'll probably create a "cli team" on github, who the people who are part of this WG and who are tackling issues (and who i talk about these issues) are part of :) 127 | 18:48 sounds good 128 | 18:48 Would it make sense for us to have a repo anyways to consolidate management of CLI related crates (if the authors desire)? 129 | 18:49 @epage what do you mean by "consolidate management" specifically? 130 | 18:50 i think that would be too many repos and too much of "jumping around" of discussions. 131 | 18:50 Thinking of your blog post, crate-ci org, assert.rs org, etc. An org to be a home for cli crates where we can help each other 132 | 18:50 i totally fine with using the cli-wg repo for planning and discussing ideas larger than crate-specific implementation details 133 | 18:51 @epage ah, i see 134 | 18:51 we could have an organisation of clique and have all the repos under it if the authors have no problems with that. That way don't have to go around hunting for crates 135 | 18:52 [Github] uazu commented in rust-lang-nursery/cli-wg on issue: Embrace Standardized Color Control https://github.com/rust-lang-nursery/cli-wg/issues/15#issuecomment-371891061 136 | 18:52 maybe. not sure if "help each other" is enough of a common thing to make up an org for tools that might do vastly different things 137 | 18:52 True 138 | 18:53 @Dylan-DPC for actual cli apps? or did you mean for libraries 139 | 18:53 i meant for libraries 140 | 18:55 I like that idea, actually. It somewhat resembles my idea of a "abandoned crates team". That way, we would join efforts towards a high-quality and maintained ecosystem for CLI libraries. 141 | 18:55 libraries make way more sense :) we can do that 142 | 18:55 To clarify, I also meant libraries 143 | 18:55 :D 144 | 18:55 :D 145 | 18:55 anyone want to create a rust-clique org? :) 146 | 18:55 like clap, config, directories, keyring, etc 147 | 18:56 okay, let's do it! 148 | 18:56 <3 awesome. 149 | 18:57 i need to leave in a few minutes, but will accept any and all github orga invites :) 150 | 18:58 done 151 | 18:58 <3 152 | 18:58 Feel free to invite me, too. 153 | 18:58 I hope I can help with things. 154 | 18:59 done 155 | 18:59 anyone else? 156 | 18:59 auto-generated avatar looks like a person with open arms, awesome :D 157 | 18:59 ## any other topics you want to discuss in this meeting? 158 | 19:00 None that I can currently think of. :-) 159 | 19:00 feel free to just start discussion stuff here ~~if~~ when you think of something :) 160 | 19:03 alright! thanks for spending an hour this friday with the CLI WG :) 161 | 19:03 :D 162 | 19:04 <3 Thank you, too! :-) 163 | 19:09 oh, just saw https://matthias-endler.de/2018/ls/ 164 | 19:10 touches/shows some stuff that's not entirely awesome in rust clis right now (sadly not using quicli) 165 | -------------------------------------------------------------------------------- /logs/2018-03-23-third-meeting.log: -------------------------------------------------------------------------------- 1 | Pascal Hertleif @killercup 19:00 2 | Welcome to the third CLI WG meeting, @/all! 3 | 4 | Dylan DPC @Dylan-DPC 19:00 5 | :tada: :tada: 6 | 7 | Kamal Marhubi @kamalmarhubi 19:00 8 | :wave: 9 | 10 | Jon Black @jonblack 19:00 11 | :beer: 12 | 13 | Pascal Hertleif @killercup 19:01 14 | what are we doing 15 | first off, let's have a look at what we are discussing in the issue tracker: https://github.com/rust-lang-nursery/cli-wg/issues?q=is%3Aissue+is%3Aopen+label%3A%22tracking+issue%22 16 | the last few weeks we've had a lot of discussions and there are bunch of bikesheds going on :) 17 | this week, i'd like to try and come to some form of consensus on each and assign issues to people who should then summarize the current state and what the WG should do about it 18 | let's start from the bottom up 19 | 20 | Dylan DPC @Dylan-DPC 19:03 21 | also we need to discuss some kind of scope, like what we are exactly supposed to do for each issue :) 22 | 23 | Pascal Hertleif @killercup 19:03 24 | yep 25 | okay, first off: the "ideal guide" rust-lang-nursery/cli-wg#6 26 | 27 | Ed Page @epage 19:04 28 | It seems like #21 also ties a little into that 29 | 30 | Pascal Hertleif @killercup 19:04 31 | does anyone want to start working on this right now? there's little discussion and rust-lang-nursery/cli-wg#21 feels like it touches similar topics 32 | (rust-lang-nursery/cli-wg#21 being "Support development of well-behaved CLI apps") 33 | 34 | Kamal Marhubi @kamalmarhubi 19:05 35 | these sound a bit too vague as stated. "support" subsumes rust-lang-nursery/cli-wg#6 I think 36 | 37 | Jon Black @jonblack 19:06 38 | I'm at a supermarket. when I'm back home in ten i can comment :) 39 | 40 | Kamal Marhubi @kamalmarhubi 19:06 41 | but also subsumes almost everything to do with CLIs 42 | 43 | Pascal Hertleif @killercup 19:06 44 | @jonblack, ah cool. no worries 45 | i was about to ask you whether you'd want to start a collaborative guide collecting best practices :) 46 | to me, rust-lang-nursery/cli-wg#6 is the deliverable we need to finish and put on the (new) rust website 47 | 48 | Dylan DPC @Dylan-DPC 19:08 49 | so what is expected from it? 50 | 51 | Pascal Hertleif @killercup 19:08 52 | rust-lang-nursery/cli-wg#21 is more of a "let's collect knowledge" effort 53 | @Dylan-DPC it should be a guide that introduces new users to rust while showing how frictionless writing a cli is and what rust has to offer 54 | 55 | Kamal Marhubi @kamalmarhubi 19:09 56 | let's clarify that in the title maybe 57 | 58 | Dylan DPC @Dylan-DPC 19:10 59 | adding it to the etherpad 60 | 61 | Pascal Hertleif @killercup 19:11 62 | @kamalmarhubi the thing is that we can also use this to drive our efforts. the "ideal" part of the guide is that we not describe how it works right now but how we want it to work 63 | 64 | Dylan DPC @Dylan-DPC 19:11 65 | or i'll just add it to the issue :D 66 | 67 | Pascal Hertleif @killercup 19:11 68 | i admit it's pretty fuzzy 69 | @Dylan-DPC add it to the issue, we can adjust the title after the meeting 70 | 71 | Kamal Marhubi @kamalmarhubi 19:12 72 | @killercup how do you see ownership of stuff in the wg? (sorry for simple procedural questions; I missed the other two meetings) 73 | 74 | Dylan DPC @Dylan-DPC 19:12 75 | done 76 | its okay @kamalmarhubi . what do you mean by ownership? 77 | 78 | Pascal Hertleif @killercup 19:12 79 | @kamalmarhubi no worries. yes, this is absolutely something this WG needs to deliver :) 80 | we can decide how we end up writing that content, of course 81 | let's talk about this later, this'll take too long for this meeting 82 | 83 | Jon Black @jonblack 19:14 84 | I think we have quite a lot of rough knowledge already. It'd be nice to turn those into example and see what we bump into. 85 | 86 | Pascal Hertleif @killercup 19:14 87 | i'll assign myself for now and promise to add more content to the issue and also talk to @jonblack about #21 :) 88 | 89 | Jon Black @jonblack 19:14 90 | I agree the guide is the main deliverable, but I'm not sure I understand how a collaborative guide would work different to what we've been doing in the issue. 91 | 92 | Kamal Marhubi @kamalmarhubi 19:14 93 | how we want it to work 94 | this makes sense. on this note, we should start thinking about proc_macro / macros 2.0 for "ideal" state. (delay talking about this for the moment) 95 | 96 | Pascal Hertleif @killercup 19:15 97 | @kamalmarhubi yeah, and cargo project templates 98 | but for now let's skip to rust-lang-nursery/cli-wg#7 -- Config file management 99 | 100 | Kamal Marhubi @kamalmarhubi 19:15 101 | what do you mean by ownership? 102 | ie, how do we think about who is responsible for moving an effort forward? 103 | 104 | Pascal Hertleif @killercup 19:15 105 | we have way more discussion there, 42 comments right now 106 | 107 | Ed Page @epage 19:16 108 | ownership 109 | I assume this also gets back to killercup's previous comment 110 | assign issues to people who should then summarize the current state and what the WG should do about it 111 | 112 | Pascal Hertleif @killercup 19:17 113 | @spacekookie you opened this issues after the first meeting and started working with @soc on directories, can you give a summary of the current state of the discussion? 114 | 115 | Kamal Marhubi @kamalmarhubi 19:17 116 | ah, yes it does. my bad :-) 117 | soc @soc says hi 118 | 119 | Pascal Hertleif @killercup 19:18 120 | @soc :wave: 121 | 122 | Katharina @spacekookie 19:19 123 | Well, currently there is the directories-rs crate which is getting some more polish. There are still some open issues about how to handle OS-specific paths (i.e. organisation names on OSX and Windows vs just application name son Linux). And then how to expose those with nice factory functions 124 | 125 | Pascal Hertleif @killercup 19:20 126 | cool. this is pretty isolated from handling reading of config files themselves, right? i.e., assuming i know which file to load, is there any ready-made solution to read that file? 127 | (i've been meaning to work on a prototype to see how to get structopt and a configuration-loading crate working together, but i haven't pushed any code yet) 128 | 129 | Katharina @spacekookie 19:20 130 | Apart from that, I think most people are in agreement about creating a crate that "just gives out configs", abstracting a lot of the boilerplate away. But it's not clear yet how or how to then allow tweaking the defaults without having to reinvent the wheel 131 | Yea, directories-rs is just about the paths, pretty disconnected with any other workflow. A more comprehensive configuration crate would wrap around that then 132 | 133 | Pascal Hertleif @killercup 19:21 134 | great, thanks for the summary! :) 135 | does anyone want to start working on a just-give-me-a-config crate? 136 | i have some ideas to get started but won't have time to work on this for at least the next 2 weeks 137 | 138 | Dylan DPC @Dylan-DPC 19:22 139 | can give it a go as long as there is someone else who knows stuff about this :D 140 | 141 | Pascal Hertleif @killercup 19:23 142 | awesome, i'll ping you after the meeting, @Dylan-DPC! 143 | 144 | Katharina @spacekookie 19:23 145 | @Dylan-DPC I was about to say the same thing x) I'd love to take the lead with it but I'm not sure I know enough about how to make it boilerplate-free without sacrificing flexibility 146 | 147 | Kamal Marhubi @kamalmarhubi 19:23 148 | I feel like the main thing to do on that is to figure out the API. there's a lot of weirdness that can happen, eg versioning of the format etc. 149 | 150 | Pascal Hertleif @killercup 19:23 151 | will ping you too @spacekookie :) 152 | 153 | Katharina @spacekookie 19:23 154 | Maybe we could team up on that then ;) 155 | 156 | Dylan DPC @Dylan-DPC 19:23 157 | :) 158 | which issue is that btw? 159 | 160 | Pascal Hertleif @killercup 19:24 161 | @Dylan-DPC rust-lang-nursery/cli-wg#7 162 | 163 | Dylan DPC @Dylan-DPC 19:24 164 | :+1: 165 | 166 | Katharina @spacekookie 19:24 167 | @killercup and his lightning reflexes :P 168 | 169 | Pascal Hertleif @killercup 19:25 170 | next up! rust-lang-nursery/cli-wg#8 - Packaging and distributing apps 171 | 172 | Ed Page @epage 19:25 173 | btw started to summarize 7 174 | 175 | Pascal Hertleif @killercup 19:25 176 | @epage i said i'd assign you last meeting and i finally did ;) 177 | @epage awesome! thanks so much! 178 | 179 | Ed Page @epage 19:25 180 | Thanks! 181 | 182 | soc @soc 19:25 183 | I think the part about handling OS-specific app names is largely done. the different functions were all reduced down to 184 | ProjectDirs::from(qualifier, organization, application) 185 | that should also be able to deal with schemes for operating systems that don't even exist right now (I hope) 186 | 187 | Ed Page @epage 19:25 188 | Already got 8 summarized 189 | 190 | Dylan DPC @Dylan-DPC 19:26 191 | @epage i have pasted @spacekookie 's comment here in the issue :) 192 | 193 | Ed Page @epage 19:26 194 | Thanks 195 | 196 | Pascal Hertleif @killercup 19:26 197 | yeah, rust-lang-nursery/cli-wg#8 has a great summary! to quote it here a bit ;) 198 | Plan of attack 199 | Process documentation 200 | Automation 201 | -- documentation is luckily also already a separate issue which we'll discuss later: rust-lang-nursery/cli-wg#23 -- 202 | 203 | Ed Page @epage 19:27 204 | Not sure about for other issues, but the assumptions section is really helpful for trying to keep the conversation on track and in scope. 205 | Are you connecting "Process documentation" with 23? 206 | 207 | Pascal Hertleif @killercup 19:29 208 | yes? ah, i see, it's "documention for the process" not "process the files to generate suitable documentation" 209 | 210 | Ed Page @epage 19:29 211 | Yup 212 | 213 | Pascal Hertleif @killercup 19:29 214 | lol, maybe change that wording ;) 215 | 216 | Ed Page @epage 19:30 217 | Improved 218 | Already had to fix 23's title when I realized it was ambiguous 219 | 220 | Pascal Hertleif @killercup 19:30 221 | :D 222 | let's make the attack plan a bit more concrete 223 | 224 | Katharina @spacekookie 19:31 225 | Talking about packaging, I don't know if this completely beyond scope but what I think would be really cool was a CLI tool that you could give some info about your application and which then generated CI files that automatically built binaries and packages for different platforms on tagged travis releases xD 226 | 227 | Kamal Marhubi @kamalmarhubi 19:31 228 | yeah! I was thinking something like a thing in the (eventual) cargo project template 229 | but a tool to help you add them to an existing project would be great too 230 | 231 | Dylan DPC @Dylan-DPC 19:32 232 | for CIs? 233 | 234 | Ed Page @epage 19:32 235 | Yeah, sounds like a mixture of templates and automation (mentioned in the issue) 236 | 237 | Pascal Hertleif @killercup 19:32 238 | @spacekookie @kamalmarhubi you mean like "copy all the files of the trust repo"? :D 239 | 240 | Ed Page @epage 19:32 241 | We first want to understand and document the process so we have a solid basis for templates and tools 242 | and to help people who can't use them for some reason 243 | 244 | Katharina @spacekookie 19:32 245 | @killercup Yes but with more :sparkles: MAGIC :sparkles: 246 | 247 | Pascal Hertleif @killercup 19:32 248 | @epage i assume the documentation should live in the crates-ci orga that already has a bunch of stuff? we can at a later point move parts of the to a more official place (say, part of the official website) 249 | 250 | Dylan DPC @Dylan-DPC 19:33 251 | i don't know whether you can generalise CI process for all users :D 252 | 253 | Ed Page @epage 19:33 254 | Yeah, thats where I was going to start the documentation 255 | 256 | Pascal Hertleif @killercup 19:33 257 | @epage sgtm! 258 | 259 | Dylan DPC @Dylan-DPC 19:34 260 | we also have the rust-clique organisation 261 | 262 | Kamal Marhubi @kamalmarhubi 19:34 263 | @Dylan-DPC fair, but you can probably generalise the build part of CI, assuming everyone's build is cargo build 264 | 265 | Dylan DPC @Dylan-DPC 19:34 266 | true. 267 | 268 | Pascal Hertleif @killercup 19:34 269 | okay, anyone feel like taking the challenge on writing the ultimate interactive ci setup tool? 270 | 271 | Katharina @spacekookie 19:34 272 | This is a really cool project https://github.com/japaric/cross 273 | I actually don't know if that's documented somewhere right now? 274 | 275 | Kamal Marhubi @kamalmarhubi 19:35 276 | I could spend some time speccing it, but not able to commit to writing it at the moment 277 | 278 | Pascal Hertleif @killercup 19:35 279 | and do we want to contribute to cargo-{deb,wix,arch} in the meantime, and others, and maybe unify them? 280 | 281 | Dylan DPC @Dylan-DPC 19:35 282 | @spacekookie cross is searching for co-maintainers :P 283 | 284 | Katharina @spacekookie 19:35 285 | @Dylan-DPC Yea the project could use some love 286 | 287 | Pascal Hertleif @killercup 19:36 288 | @kamalmarhubi speccing sounds like you want to contribute to https://github.com/crate-ci/crate-ci.github.io 289 | 290 | Katharina @spacekookie 19:36 291 | I actually had some issues with dependencies and having to write my own Dockerfile's. Wondering if it would be possible to generate them somehow 292 | 293 | Pascal Hertleif @killercup 19:36 294 | @Dylan-DPC there are plans to integrate xargo into cargo, though, that'll make some new stuff possible 295 | 296 | Ed Page @epage 19:37 297 | I was starting on a "stager" crate (after I do my assert_cli work) to make it easier to organize the files for packaging. Once I got that in, I was going to reach out to the cargo-deb, etc crates to see if they want to help "unify" using stager 298 | 299 | Dylan DPC @Dylan-DPC 19:37 300 | @spacekookie even i wanted to generate them for some reason :joy: 301 | 302 | Ed Page @epage 19:37 303 | For now, stager was just going to make it easier to create tarballs for github 304 | 305 | Kamal Marhubi @kamalmarhubi 19:37 306 | @killercup 307 | speccing sounds like you want to contribute to https://github.com/crate-ci/crate-ci.github.io 308 | seems unrelated? 309 | 310 | Katharina @spacekookie 19:37 311 | @killercup Having a single packaging crate with modules could be cool. The same way that "clippy" is all the lints :P 312 | 313 | Ed Page @epage 19:38 314 | @kamalmarhubi 315 | crate-ci's focus is on documenting and streamlining crate management, including packaging 316 | So if you want to spec packaging stuff, that could be a good place 317 | 318 | Pascal Hertleif @killercup 19:38 319 | @epage is stager meant to use custom adaptors it can call out to? 320 | 321 | Kamal Marhubi @kamalmarhubi 19:38 322 | with dependencies and having to write my own Dockerfile's 323 | this is a big problem. is there an issue for non-crates.io dependencies? 324 | 325 | Ed Page @epage 19:38 326 | Stager only lays out files on disk. The tools will then suck up those files. It will have plugins for custom sources, like cargo (to get the bin) 327 | 328 | Katharina @spacekookie 19:39 329 | @kamalmarhubi My problem was with ncurses and ncursesw 330 | 331 | Pascal Hertleif @killercup 19:39 332 | @epage sounds great (just what i'd do :D) 333 | 334 | Ed Page @epage 19:39 335 | I'm basing stager off of real world installer tools I've seen internal to businesses 336 | My main motivation for stager is I was trying to document tarballing and its really annoying adding it to a CI process because of how much extra book keeping is needed to find the bin 337 | 338 | Kamal Marhubi @kamalmarhubi 19:40 339 | @spacekookie yeah that's a problem. if there's not an issue for it, we should file one! 340 | 341 | Katharina @spacekookie 19:40 342 | @kamalmarhubi You mean in cross or the CLI-WG? 343 | 344 | Ed Page @epage 19:41 345 | I've explicitly called out stager on 8 346 | 347 | Katharina @spacekookie 19:41 348 | I mean, the cross README basically says to build your own Docker container but the workflow is a bit cumbersome 349 | 350 | Pascal Hertleif @killercup 19:41 351 | @epage i think focussing on having a unified interface that can give you nicely packaged stuff is a huge thing. could pay off greatly or also not work well enough for people to use 352 | 353 | Kamal Marhubi @kamalmarhubi 19:41 354 | CLI-WG. CLI tools will often have non-rust dependencies. we should at least have guidance for it. ideally we Solve the Problem but that's a larger, ecosystem wide thing. 355 | 356 | Pascal Hertleif @killercup 19:42 357 | @epage do you think you can get a MVP ready in the next ~2 weeks and then we can ask contributors/authors of cargo-{deb,…}/users what they think? 358 | 359 | Ed Page @epage 19:42 360 | @killercup 361 | or also not work well enough for people to use 362 | The importance of the documentation and having composable tools like stager :) 363 | I was trying to get my MVP of assert_cli implemented first. Would you prefer me to priorize stager instead? 364 | 365 | Kamal Marhubi @kamalmarhubi 19:43 366 | is this a new assert_cli? 367 | 368 | Ed Page @epage 19:43 369 | @kamalmarhubi see rust-lang-nursery/cli-wg#9 370 | 371 | Pascal Hertleif @killercup 19:43 372 | @epage maybe. great transition, though! 373 | 374 | Dylan DPC @Dylan-DPC 19:43 375 | i think let's get back to the issues :P 376 | 377 | Pascal Hertleif @killercup 19:43 378 | next up: testing cli apps -- rust-lang-nursery/cli-wg#9 379 | let's rush the next ones a bit, we're already at 75% of the time slot 380 | 381 | Ed Page @epage 19:44 382 | Issue is summarized. I've got a small fraction of a prototype implemented for where we plan to take all of these 383 | 384 | Pascal Hertleif @killercup 19:45 385 | i think rust-lang-nursery/cli-wg#9 is pretty unchanged, and has a great summary. @epage and i are working on the next assert_cli 386 | (i'll join back in next week! yay!) 387 | 388 | Dylan DPC @Dylan-DPC 19:45 389 | great :) 390 | 391 | Pascal Hertleif @killercup 19:45 392 | aaaaand next: rust-lang-nursery/cli-wg#10 Cross-platform file system abstractions 393 | 394 | Ed Page @epage 19:45 395 | My preference then is to focus on assert_cli rather than stager so I can have some decent ground work layed for when you come back 396 | 397 | Pascal Hertleif @killercup 19:46 398 | @epage yeah, maybe work on assert_cli next week and then we'll talk the next weekend? 399 | 400 | Ed Page @epage 19:46 401 | Sure 402 | 403 | Pascal Hertleif @killercup 19:47 404 | so rust-lang-nursery/cli-wg#10 is kinda related. @epage i think you also proposed this in the first meeting 405 | 406 | Ed Page @epage 19:47 407 | Don't remember why 408 | 409 | Pascal Hertleif @killercup 19:48 410 | @vitiral started https://github.com/vitiral/path_abs 411 | which seems to address some of the "higher level path" points 412 | anyone want to work on this? 413 | 414 | Ed Page @epage 19:49 415 | I think #10 needs a summary and some more requirement gathering. I've seen two things recently (1) concerns over reading paths from files and (2) someone complaining about relative paths within Path/PathBuf. I wish I had kept track of them and noted them on this issue. 416 | I'll at least do a summary for it and look some more for those posts I saw so we can try to get more input 417 | 418 | Pascal Hertleif @killercup 19:50 419 | yeah i'm reading through the comments right now too… let's come back to this at a later date 420 | next: rust-lang-nursery/cli-wg#11 Improve ecosystem discoverability 421 | so far we've started/worked on at least 3 github orgas for cli stuff and i think we have some good unification efforts going 422 | i'd like to have some points of this become part of the "general rust best practices", like cross-linking related crates 423 | 424 | Katharina @spacekookie 19:52 425 | I don't know what's planned so far with the new Rust homepage but having a canonical selection of crates "How to write a CLI" could be a nice start? 426 | 427 | Ed Page @epage 19:52 428 | That might be good to note on the maintainership guide issue, rust-lang-nursery/ecosystem-wg#10 429 | (cross linking) 430 | 431 | Pascal Hertleif @killercup 19:53 432 | @spacekookie maybe. also dangerous, could go stale quickly 433 | @epage ah yes, we can totally work with the new ecosystem wg on this! 434 | next: rust-lang-nursery/cli-wg#12 Error handling in CLI apps 435 | 436 | Ed Page @epage 19:54 437 | I know discoverability is a common discussion point point for crates.io. Do we know if finding "if you want to use this crate, people also use creates X with it" has ever come up? 438 | an automated cross-linking 439 | 440 | Pascal Hertleif @killercup 19:54 441 | @epage not sure, i'll ask around 442 | so for #12 we have quite good news: rust-lang/rust#43301 443 | ? in main is pretty close to stable 444 | 445 | Dylan DPC @Dylan-DPC 19:55 446 | @epage we could have a "suggest" section in Cargo.toml where in you can suggest other crates to the user. I have seen it in other package managers. 447 | 448 | Pascal Hertleif @killercup 19:55 449 | as in, it'll totally be in rust 2018 450 | 451 | Kamal Marhubi @kamalmarhubi 19:55 452 | :sparkles: 453 | 454 | Ed Page @epage 19:55 455 | Yay! 456 | @Dylan-DPC I'm hoping for a more automated approach looking at a crate's direct dependencies 457 | 458 | Dylan DPC @Dylan-DPC 19:56 459 | ok 460 | 461 | Pascal Hertleif @killercup 19:56 462 | the more complicated issue is outputting good errors and exiting with good error codes… 463 | 464 | Kamal Marhubi @kamalmarhubi 19:56 465 | we could have a "suggest" section in Cargo.toml 466 | and then implement pagerank :-) 467 | 468 | Pascal Hertleif @killercup 19:57 469 | rust loves bots, why not add one that uses a bit machine learning to help you find just the crates you need? :D 470 | 471 | Ed Page @epage 19:57 472 | Hasn't @BurntSushi brought up issues with broken pipes or something? Not seeing it brought up in 12 473 | 474 | Katharina @spacekookie 19:58 475 | crates.io just needs a good recommender algorithm. 476 | "People who used this crate also liked this other crate" :joy: 477 | 478 | Kamal Marhubi @kamalmarhubi 19:58 479 | it was in a different issue 480 | 481 | Pascal Hertleif @killercup 19:58 482 | it was in #21 i think 483 | 484 | Kamal Marhubi @kamalmarhubi 19:58 485 | on handling stdio and such 486 | 487 | Pascal Hertleif @killercup 19:59 488 | damn, we're almost at the end of the time box already 489 | we have too many things! 490 | 491 | Dylan DPC @Dylan-DPC 19:59 492 | maybe extend it? :P 493 | 494 | Pascal Hertleif @killercup 19:59 495 | let me just add two things and then we can officially end the meeting but you are welcome to keep discussing stuff :) 496 | 497 | Ed Page @epage 19:59 498 | I think the important thing is find owners for each so we don't have to discuss it all right now 499 | 500 | Kamal Marhubi @kamalmarhubi 20:00 501 | :+1: 502 | 503 | Pascal Hertleif @killercup 20:00 504 | 995 survey responses!! 505 | 506 | Katharina @spacekookie 20:00 507 | When are the results gonna be published? 508 | 509 | Pascal Hertleif @killercup 20:00 510 | they survey ends tomorrow 511 | 512 | Kamal Marhubi @kamalmarhubi 20:00 513 | link? I want to share it with my internets 514 | 515 | Pascal Hertleif @killercup 20:01 516 | i'll present preliminary results at the all hands monday morning 517 | @kamalmarhubi https://goo.gl/forms/WQhNGOG723JobeEf2 518 | which also brings me to: 519 | who'll be at the rust all hands? :D 520 | 521 | Ed Page @epage 20:01 522 | I wish :) 523 | 524 | Katharina @spacekookie 20:03 525 | @killercup I will be but you know that ;) 526 | 527 | Pascal Hertleif @killercup 20:03 528 | there are two time slots for the cli wg, and i want to use them to discuss (a) what we need from the other teams and (b) how to get all that marketing goodness going 529 | 530 | Kamal Marhubi @kamalmarhubi 20:04 531 | what is rust all hands? 532 | (I'm so out of the loop!) 533 | 534 | Pascal Hertleif @killercup 20:04 535 | @kamalmarhubi meeting of rust team members, next week at the mozilla office in berlin 536 | 537 | Kamal Marhubi @kamalmarhubi 20:05 538 | oh man. yeah I won't be there. it'd be great though... 539 | 540 | Pascal Hertleif @killercup 20:05 541 | i'll post here when i know the final schedule, and you're all very welcome to at least virtually join 542 | 543 | Dylan DPC @Dylan-DPC 20:05 544 | sounds cool :) 545 | 546 | Pascal Hertleif @killercup 20:06 547 | okay, well, i guess this marks the end of the official meeting :) 548 | -------------------------------------------------------------------------------- /logs/2018-05-03-packaging.log: -------------------------------------------------------------------------------- 1 | Ed Page @epage May 03 12:00 2 | Welcome everyone! 3 | 4 | ashley williams @ashleygwilliams May 03 12:00 5 | hello! 6 | 7 | Ed Page @epage May 03 12:00 8 | I'll be taking notes at https://public.etherpad-mozilla.org/p/crate-packaging 9 | That also has some ideas for us to talk about 10 | 11 | Just to get the conversation started while we wait for people to trickle in, I've gotten a prototype of stager created. 12 | https://github.com/crate-ci/stager 13 | 14 | stager is a general mechanism to describe how you want to layout files and whee they are sourced from. My hope is that we can use this as a shared language / mechanism for each of our packaging tools 15 | Also, as part of my goal of dropping trust boiler plate down to 0, I've started on the first client of stager, cargo-tarball 16 | https://github.com/crate-ci/cargo-tarball 17 | I'm dogfooding cargo-tarball to guide me in what features to develop. 18 | So far its configuration 19 | https://github.com/crate-ci/cargo-tarball/blob/master/tarball-config.yml 20 | and hand-authored data that we want to eventually harvest 21 | https://github.com/crate-ci/cargo-tarball/blob/master/data/crate.yml 22 | 23 | Pascal Hertleif @killercup May 03 12:04 24 | i have but one question: is it self hosting releasing yet? :smiley: 25 | 26 | Ed Page @epage May 03 12:05 27 | Working towards it. I think by this weekend it will be. 28 | 29 | Pascal Hertleif @killercup May 03 12:06 30 | very cool 31 | can you talk a bit about what the config files are supposed to tell us? 32 | i assume the tarball-config lists a bunch of target files and how to build them? 33 | 34 | Ed Page @epage May 03 12:07 35 | Where to source them from, yes 36 | The root directory being the root of the tarball 37 | SourceFiles uses the awesome globwalk and can support one or more patterns 38 | 39 | Pascal Hertleif @killercup May 03 12:08 40 | i see, so SourceFiles is basically an interface for a clever cp 41 | 42 | Ed Page @epage May 03 12:08 43 | I don't have that great of documentation yet. For the schema, its best to look at 44 | https://docs.rs/stager/0.3.4/stager/de/index.html 45 | https://github.com/crate-ci/cargo-tarball/blob/master/src/de.rs#L18 46 | Yup 47 | 48 | Pascal Hertleif @killercup May 03 12:08 49 | i'm asking because "{{cargo.target_directory}}/debug/build/cargo-tarball-b8d713fa01725c21/out/completions" looks pretty fragile 50 | 51 | Ed Page @epage May 03 12:09 52 | Yes, that is why I don't consider it self-releasing yet 53 | If you look at that file, its been improving 54 | *files history 55 | 56 | Pascal Hertleif @killercup May 03 12:10 57 | cool 58 | 59 | Ed Page @epage May 03 12:10 60 | Still unsure if we should have the configuration in a Cargo.toml [metadata] or have a distinct file for all packaging needs 61 | 62 | Pascal Hertleif @killercup May 03 12:10 63 | what's your ideal version of this file? do you envision having a "CargoBin" type as well? 64 | 65 | Ed Page @epage May 03 12:10 66 | The idea would be to have tiered configuration. There is per-package system configuration that would merge in defaults from a global configuration 67 | 68 | Kornel @kornelski May 03 12:11 69 | Sorry, I don't get what stager is for. Who's the user of it - crate author? os-specific packaging crate? 70 | 71 | Pascal Hertleif @killercup May 03 12:11 72 | putting that into Cargo.toml sounds good to me, if it's not too verbose 73 | 74 | Ed Page @epage May 03 12:11 75 | @kornelski 76 | os-specific packaging crates 77 | 78 | Pascal Hertleif @killercup May 03 12:11 79 | i think stager should eventually be able to drive tools like cargo-deb and cargo-rpm, right? 80 | 81 | Ed Page @epage May 03 12:12 82 | @killercup There might later be a CargoBin. Its not absolutely needed as an MVP so I'm going to wait and see how that evolves 83 | @killercup thats the idea. I'm actually taking the idea from how my company supports distributing binaries for multiple package management systems 84 | I think someone else pointed out a similar non-rust open source project 85 | 86 | Kornel @kornelski May 03 12:13 87 | how does crate author interact with stager, e.g. to define post-install scripts? 88 | 89 | Ed Page @epage May 03 12:13 90 | https://sbt-native-packager.readthedocs.io/en/stable/ 91 | 92 | Dylan DPC @Dylan-DPC May 03 12:13 93 | so it pushes to apt, rpm etc on linux? 94 | 95 | Ed Page @epage May 03 12:15 96 | @kornelski this is used for laying out files that will get installed. A crate author might create a config like this 97 | https://github.com/crate-ci/cargo-tarball/blob/master/tarball-config.yml 98 | iirc postinst scripts don't generally get treated as normal files, so a cargo-made-up-pkg-format generally wouldn't use stager for those 99 | 100 | Pascal Hertleif @killercup May 03 12:15 101 | insert killercup anti-auto-publishing rant here 102 | 103 | Dylan DPC @Dylan-DPC May 03 12:15 104 | :joy: 105 | 106 | Kornel @kornelski May 03 12:16 107 | @epage that's not made up pkg format, that's deb, and an existing feature of cargo-deb 108 | 109 | Ed Page @epage May 03 12:16 110 | @Dylan-DPC stager is a general format, independent of types. Someone could then describe their artifacts using stager for cargo-tarball. That will create the package but then you need to distribute it 111 | 112 | Dylan DPC @Dylan-DPC May 03 12:17 113 | okay 114 | 115 | Ed Page @epage May 03 12:17 116 | @kornelski I was saying for example purposes and didn't want to prescribe that cargo-deb use stager though I'd like them to 117 | 118 | Kornel @kornelski May 03 12:17 119 | I'm the developer of cargo-deb, and I'm trying to, so that's why I'm here 120 | 121 | Ed Page @epage May 03 12:18 122 | Oh, cool 123 | (can't remember who maintains what) 124 | 125 | So stager would fill the role of describing assets 126 | 127 | assets: Files to be included in the package and the permissions to assign them. If assets are not specified, then defaults are taken from binaries explicitly listed in [[bin]] (copied to /usr/bin/) and package readme (copied to usr/share/doc/…). 128 | 129 | 130 | Pascal Hertleif @killercup May 03 12:19 131 | @epage i assume stager would be able to forward config values to the package impl it calls, so if you have a [metadata.deb] section it could foward that to cargo-deb, right? 132 | 133 | Ed Page @epage May 03 12:19 134 | More like cargo-deb would forward its assets section to stager 135 | 136 | Pascal Hertleif @killercup May 03 12:19 137 | ah okay 138 | 139 | Kornel @kornelski May 03 12:19 140 | the assets thing has problems, e.g. the docs should get gz-compressed before being put in deb 141 | I do that automatically for crate's own readme 142 | 143 | Ed Page @epage May 03 12:20 144 | Good to know, I've created crate-ci/stager#18 145 | Please add any more requirements you are aware of 146 | 147 | Kornel @kornelski May 03 12:21 148 | another issue is cargo uses different target directory layout when cross-compiling 149 | so I have logic to automagically correct target/release/foo to the correct path 150 | 151 | Pascal Hertleif @killercup May 03 12:21 152 | stager does… stages, right? so, is "generating man pages" a stage and "compress a bunch of the files we collected" another stage? 153 | @kornelski does cargo builds json output give you any useful information there? 154 | 155 | Ed Page @epage May 03 12:22 156 | It stages as in it drops everything into an intermediate location. Some forms of data generation will still be on the client though general ones we can build in, like compressing 157 | 158 | Kornel @kornelski May 03 12:22 159 | and debian package is a russian doll of ( xz archive + gz archive + metadata ) all in ar archive 160 | 161 | Pascal Hertleif @killercup May 03 12:22 162 | hahaha 163 | sent over http with deflate on 164 | 165 | Kornel @kornelski May 03 12:23 166 | @killercup I use cargo metadata for some things, but it's woefully incomplete 167 | 168 | Ed Page @epage May 03 12:23 169 | Compressing the staged directory is left to the client. cargo-tarball currently does this 170 | https://github.com/crate-ci/cargo-tarball/blob/master/src/compress.rs 171 | 172 | Kornel @kornelski May 03 12:23 173 | so I then parse cargo.toml 174 | and the rest is based on shoddy assumptions :grinning: 175 | 176 | Ed Page @epage May 03 12:23 177 | Yeah, @kornelski the incompleteness is what I'm currently running into 178 | 179 | Pascal Hertleif @killercup May 03 12:23 180 | have you bugged the cargo team about that? 181 | i can mention this to them as something that's blocking cli-wg progress if you want me to 182 | 183 | Ed Page @epage May 03 12:24 184 | I think the problem is that cargo-metadata is effectively describing the manifest file. We're needing environment information 185 | 186 | Pascal Hertleif @killercup May 03 12:24 187 | yeah, that's why i asked about cargo-build's ouput 188 | 189 | Ed Page @epage May 03 12:25 190 | That was what I was going to look into next 191 | Granted this issue might help 192 | https://github.com/rust-lang/cargo/pull/5203#issuecomment-380442967 193 | @kornelski how I planned to structure cargo-tarball is that it will have a default policy for how to automatically stage common patterns (bins, completions). The user can then augment that stage or disable it and completely control it 194 | I provide variable substitutions to help the user construct their staged configuration 195 | 196 | Pascal Hertleif @killercup May 03 12:29 197 | fyi, compiling cargo-fix with cargo build --message-format json | jq i get: 198 | ```json 199 | 200 | ... 201 | { 202 | "features": [], 203 | "filenames": [ 204 | "/Users/pascal/Projekte/rustfix/target/debug/cargo-fix", 205 | "/Users/pascal/Projekte/rustfix/target/debug/cargo-fix.dSYM" 206 | ], 207 | "fresh": true, 208 | "package_id": "cargo-fix 0.2.0 (path+file:///Users/pascal/Projekte/rustfix/cargo-fix)", 209 | "profile": { 210 | "debug_assertions": true, 211 | "debuginfo": 2, 212 | "opt_level": "0", 213 | "overflow_checks": true, 214 | "test": false 215 | }, 216 | "reason": "compiler-artifact", 217 | "target": { 218 | "crate_types": [ 219 | "bin" 220 | ], 221 | "kind": [ 222 | "bin" 223 | ], 224 | "name": "cargo-fix", 225 | "src_path": "/Users/pascal/Projekte/rustfix/cargo-fix/src/main.rs" 226 | } 227 | } 228 | ``` 229 | 230 | which is only semi-helpful as there is no information which of the filenames is a useful binary 231 | 232 | Kornel @kornelski May 03 12:30 233 | Yes, I might have had the same problem 234 | 235 | Ed Page @epage May 03 12:31 236 | RE rust-lang/cargo#5203 it seems like this could be useful for build.rs generated artifacts and not just choosing where to output the binary. @killercup mind looking over that and chiming in? 237 | Not sure if its just I've not been clear about how that helps the CLI-WG or if I don't understand the complications from the cargo side of providing it 238 | 239 | Kornel @kornelski May 03 12:31 240 | and the binary is .exe on windows, and you can't use https://doc.rust-lang.org/std/env/consts/index.html to get the extension, because it doesn't work for cross-compiling 241 | rust-lang/cargo#5457 242 | regarding building of other artifacts, I assumed OUT_DIR is for temporary/private stuff that isn't an end-product 243 | 244 | Ed Page @epage May 03 12:33 245 | Yup but afaik there isn't yet a different place to output them to? Resolving your issue would give us that 246 | 247 | Kornel @kornelski May 03 12:34 248 | Yeah, so I think exposing CARGO_TARGET_DIR to build.rs would make sense here 249 | 250 | Ed Page @epage May 03 12:34 251 | I'm not fully aware of each variable and its intent but the intent I agree with 252 | 253 | Kornel @kornelski May 03 12:36 254 | xcode has BUILT_PRODUCTS_DIR https://help.apple.com/xcode/mac/8.0/#/itcaec37c2a6 255 | 256 | Pascal Hertleif @killercup May 03 12:37 257 | @epage not sure i follow the --out-dir issue 258 | 259 | Ed Page @epage May 03 12:37 260 | Ok, so far, we've talked about 261 | 262 | platform-requirements for assets, like compressing them 263 | challenges of finding assets, including cargo changing where it out puts it depending on circumstances and dealing with .exe when cross-compiling 264 | stager as a possible common way of specifying additiional assets 265 | 266 | @killercup Its related to rust-lang/cargo#5457 267 | --out-dir seems to be a mechanism to make it easier to find specific final artifacts (the binary). I was bringing up the concern about build.rs possibly creating other final, and not temporary, artifacts, like completions. 268 | and not having a way to find them 269 | As was pointed out, my current way of getting completions is broken 270 | path: "{{cargo.target_directory}}/debug/build/cargo-tarball-b8d713fa01725c21/out/completions" 271 | I was bringing up the idea of exposing --out-dir as an environment variable for build.rs 272 | 273 | Dylan DPC @Dylan-DPC 12:40 274 | what is completions? 275 | 276 | Ed Page @epage May 03 12:40 277 | completions are scripts to augment your shell so you can tab complete command line arguments like you do file paths 278 | 279 | Dylan DPC @Dylan-DPC 12:41 280 | ah that okay :grinning: thx 281 | 282 | Ed Page @epage May 03 12:41 283 | Its an easy illustration of final artifacts 284 | 285 | Kornel @kornelski 12:42 286 | Are there use-cases for packaging workspaces? mmstick/cargo-deb#49 287 | 288 | Pascal Hertleif @killercup 12:42 289 | @epage how would --out-dir change the name of the artifact? 290 | oh, because you only care about the hashed directory name for the files you generate yourself and put in the out dir, got it 291 | 292 | Ed Page @epage May 03 12:44 293 | Yeah, so if the user specifies where they want final artifacts written, I have some mechanism for my build.rs artifacts to also go there so I don't have to try to find them in a hashed directory 294 | @kornelski workspaces are a beast I've completely ignored for now :worried: 295 | Do you release all crates in lock step or tag the repo individually? If the latter, we need to work out a consistent practice for doing so so a CI can recognize what is getting released and only cargo-deb that one 296 | 297 | Kornel @kornelski 12:46 298 | Current implementation in cargo-deb is to use whatever cargo metadata provides, which I think gives it a flattened view of the workspace 299 | 300 | Ed Page @epage May 03 12:47 301 | Do you then gather artifacts from each package? 302 | @kornelski What are your thoughts on cargo-deb using stager for describing artifacts, whether the user defined ones or the built-in ones? 303 | 304 | Kornel @kornelski 12:48 305 | Yes I currently build a single package from all exe/dylib targets found in metadata 306 | 307 | Ed Page @epage May 03 12:48 308 | Seems reasonable. 309 | 310 | Kornel @kornelski 12:49 311 | but I've got feedback it's important to support packaging of "leaf" subprojects in a cargo workspace 312 | (which happens to work fine if you point cargo metadata to the right Cargo.toml) 313 | 314 | Pascal Hertleif @killercup 12:50 315 | workspaces where there is only one binary crate seem common 316 | at least on my machine :wink: 317 | 318 | Kornel @kornelski 12:50 319 | I do have use-case for packaging an LGPL part separately as a library 320 | but I currently handle that manually 321 | 322 | Ed Page @epage May 03 12:51 323 | Licensing and legal notices are a fun can of worms I've not even tried to look into 324 | Partially because I know someone who knows a lot about the intricacies and want to get him involved but he is currently doing crunch time at work 325 | 326 | Kornel @kornelski 12:52 327 | handling of crate licenses is an orthogonal problem, so I think it's fine to ignore 328 | but one workspace producing separate packages for libraries and binaries needs to be supported 329 | 330 | Ed Page @epage May 03 12:54 331 | Well, and if we're doing things in the most ideal way, we'd also want to create distinct arch-agnostic packages from arch packages 332 | 333 | Kornel @kornelski 12:54 334 | In cargo-deb what I really want to do is to free user from knowing quirks of Debian 335 | there are hundreds of tiny rules Debian has for packages ( see lintian) 336 | 337 | Ed Page @epage May 03 12:54 338 | Understandable though there are limits to that 339 | I'm going through that for red hat right now as for $DAY_JOB I'm in the middle of creating ~50 packages 340 | and will eventually get hit with debs 341 | 342 | Kornel @kornelski 12:55 343 | so for example I automatically apply the "changelog should be gzipped" rule 344 | 345 | Ed Page @epage May 03 12:56 346 | For handling distinct packages, one thought I was having was that the packaging configuration would be an array so people can declare independent packages. Initially, they'd have to turn off the default config and handle everything manually (with helpers) but as we work out the design, we could have ways to specify what goes in our out with basic rules 347 | 348 | Kornel @kornelski 12:56 349 | so if I were to use stager, I'd like to supply that information to stager, so that crate author doesn't have to gzip themselves, nor even configure something like extra docs-gzip stage 350 | 351 | Pascal Hertleif @killercup 12:57 352 | ideally, you'd have a set of well-known files, right? 353 | 354 | Ed Page @epage May 03 12:58 355 | Interesting use case and point. 356 | stager doesn't know anything about debs and wouldn't know to do that. 357 | You could do a transform on the stager results before processing them, adding the yet-to-be-made compression flag for when needed? 358 | 359 | Pascal Hertleif @killercup 12:58 360 | see a {CHANGELOG,RELEASES}{.md,.txt}, pick it up, and package it as a gz file 361 | 362 | Ed Page @epage May 03 12:58 363 | or if its in your built-in rules, youcould auto-set it? 364 | 365 | Kornel @kornelski 13:00 366 | yes, something like rules/file transformations inserted by the packaging crate. 367 | 368 | Ed Page @epage May 03 13:00 369 | Thanks for helping to find these different cases I'm not aware of yet :grinning: 370 | 371 | Kornel @kornelski 13:00 372 | There's more! 373 | In debian there are separate -dbg crates 374 | so if you have a binary with debugging symbols, you extract the symbols to a separate file, and produce two packages: binary + dbg 375 | so user can add debug symbols at any time later 376 | (the debug symbols package doesn't contain the binary, just the additional files) 377 | 378 | Dylan DPC @Dylan-DPC 13:02 379 | is all this documented somewhere? 380 | 381 | Kornel @kornelski 13:02 382 | mmstick/cargo-deb#62 383 | 384 | Dylan DPC @Dylan-DPC 13:02 385 | cool 386 | 387 | Ed Page @epage May 03 13:02 388 | @Dylan-DPC there are huge swathes of documentation. The problem is processing it and deciding what to handle handle, and hw 389 | 390 | Dylan DPC @Dylan-DPC 13:02 391 | fair. just some place we can refer later and tick some boxes 392 | 393 | Ed Page @epage May 03 13:03 394 | @kornelski speaking of challenges, are you handling multiarch? 395 | 396 | Kornel @kornelski 13:03 397 | I do support cross-compilation 398 | cargo-deb almost works on Windows :smiley: 399 | 400 | Ed Page @epage May 03 13:04 401 | I assume you somehow get the rust target triplet and convert it to the debian triplet? 402 | 403 | Kornel @kornelski 13:04 404 | yes 405 | there's a messy match somewhere in the code 406 | 407 | Ed Page @epage May 03 13:05 408 | https://github.com/mmstick/cargo-deb/blob/master/src/manifest.rs#L697 409 | Hmm, not that one since it doesn't seem to create the triplet. I assume that helps create the triplet? 410 | 411 | Kornel @kornelski 13:08 412 | it's not the full triplet, since the linux- part is not required :wink: 413 | 414 | Pascal Hertleif @killercup 13:09 415 | i'm going to run off to get dinner before diving into the next meeting 416 | 417 | Ed Page @epage May 03 13:09 418 | Thanks! 419 | Looking at my company's multiarch support, it seems the last part of the triplet can get special when dealing with arm 420 | 421 | Pascal Hertleif @killercup 13:10 422 | cc me on any issues you want me to raise/you have raised concerning other teams and i'll try to track them 423 | 424 | Ed Page @epage May 03 13:10 425 | Will do 426 | 427 | Kornel @kornelski 13:11 428 | yes, I've had bugs because of ARM abi 429 | 430 | Ed Page @epage May 03 13:11 431 | 432 | yes, I've had bugs because of ARM abi 433 | 434 | I've not dealt with our arm support but from what I've heard second hand, this statement is fully valid outside of this context :grinning: 435 | 436 | Kornel @kornelski 13:11 437 | the lesson was don't use std::env::ARCH 438 | it's ambiguous on ARM 439 | and cargo doesn't pass TARGET to lib.rs 440 | so I've had to do ugly hack of writing TARGET to a file in OUT_DIR and reading it from there 441 | 442 | Ed Page @epage May 03 13:14 443 | So that ties your arch to what mode cargo-deb is compiled in? 444 | 445 | Kornel @kornelski 13:14 446 | It's used to know the default when user doesn't pass --target 447 | 448 | Ed Page @epage May 03 13:15 449 | Ok 450 | Ideally we could find a way to know what target rustup currently has configured and we make that the default but that seems like a lot more investigation and work. 451 | For now, I'll steel yours :grinning: 452 | 453 | Kornel @kornelski 13:17 454 | I'm waiting until rust adopts a better linker. My dream is to make Linux packages from my Mac :grinning: 455 | 456 | Ed Page @epage May 03 13:17 457 | That would be the dream 458 | 459 | I probably need to head out. My plan is to organize the notes and post them to the CLI-WG git repo for review / submission. 460 | 461 | Hopefully from there we can continue discussion on where we can share effort 462 | btw have you given any thought to ppas or some sort? 463 | 464 | Kornel @kornelski 13:20 465 | In what sense? 466 | 467 | Ed Page @epage May 03 13:21 468 | How do you (and for how much you know) your users distributing their debs? 469 | I'm wondering what we can do to make it easier for any random CLI author to make it easy for their usrs to install a version and then get updates without having to go back and downlaod 470 | 471 | Kornel @kornelski 13:22 472 | I know some use private repositories 473 | but I haven't got any feature requests related to that, so I assume it's straightforward to publish once you have a deb 474 | for me the biggest pain in distribution has been code signing 475 | 476 | Ed Page @epage May 03 13:23 477 | Yeah, haven't had to deal with that with rpms but I've been warned for when I do debs 478 | 479 | Kornel @kornelski 13:25 480 | with code signing I mean macos and windows actually. I distribute debs as-is (in debs signing is part of the repository, not the package, I think) 481 | 482 | Ed Page @epage May 03 13:25 483 | oh, right 484 | 485 | Kornel @kornelski 13:26 486 | on windows signature is in the exe 487 | so it needs to be applied before packaging 488 | on macos it's either directory adjacent to the exe or an extended file attirbute 489 | 490 | Ed Page @epage May 03 13:27 491 | I assume your interest in this is for tools besides cargo-deb or are you somehow using debs on windows? 492 | 493 | Kornel @kornelski 13:27 494 | the latter is pretty bad, since zip/tar removes extended attrs, so executables after unzipping stop working 495 | I'm not using debs on windows 496 | my interest is in distributing my apps on various platforms, linux being one, so I ended up improving cargo-deb to my liking :grinning: 497 | but I'm also starting work on cargo-brew 498 | 499 | Ed Page @epage May 03 13:28 500 | Nice 501 | I saw there is a cargo-wix. After I finish up with some of the my current stuff I want to look into that and address issues there. 502 | Granted, for myself, I think I'd prefer a cargo-chocolatey 503 | 504 | -------------------------------------------------------------------------------- /logs/2018-05-03-packaging.md: -------------------------------------------------------------------------------- 1 | Existing packaging systems 2 | - [cargo-deb](https://github.com/mmstick/cargo-deb) 3 | - [cargo-wix\](https://github.com/volks73/cargo-wix) 4 | - [cargo-arch](https://crates.io/crates/cargo-arch) 5 | - [cargo-rpm](https://github.com/iqlusion-io/crates/tree/master/cargo-rpm) 6 | - [cargo-ebuild](https://github.com/cardoe/cargo-ebuild) 7 | - [cargo-tarball](https://github.com/crate-ci/cargo-tarball) 8 | 9 | Related distribution methods 10 | - [self_update](https://github.com/jaemk/self_update) 11 | - [trust](https://github.com/japaric/trust/) 12 | 13 | ## Challenges in packaging 14 | 15 | ### Finding binary artifacts 16 | 17 | Challenges 18 | - Cross-compiling puts items under a different folder 19 | 20 | Possible solutions 21 | - Cargo gained support for an `--out-dir`, see [rust-lang/cargo#5203](https://github.com/rust-lang/cargo/pull/5203) 22 | - When available in stable? 23 | 24 | ### Finding `build.rs` artifacts 25 | 26 | Examples 27 | - Completions 28 | - man pages 29 | 30 | Challenges 31 | - `build.rs` scripts generally write to 32 | [`OUT_DIR`](https://doc.rust-lang.org/cargo/reference/environment-variables.html#environment-variables-cargo-sets-for-build-scripts) 33 | which have non-predictable paths like 34 | `target/debug/build/cargo-tarball-b8d713fa01725c21/out/`. 35 | 36 | Existing discussions 37 | - [How to get OUT_DIR without running the build script?](https://users.rust-lang.org/t/how-to-get-out-dir-without-running-the-build-script/17239/3) 38 | - [Location of generated non-binary artifacts](https://internals.rust-lang.org/t/location-of-generated-non-binary-artifacts/7430) 39 | 40 | Workarounds: 41 | - Don't use `build.rs` but generate an extra `bin` target to build these as part of the CI 42 | 43 | Possible solutions 44 | - [rust-lang/cargo#5457](https://github.com/rust-lang/cargo/issues/5457) 45 | 46 | ### Misc 47 | 48 | - Knowing the `bin` name 49 | - On Windows, it will have a `.exe` extension 50 | - Could use https://doc.rust-lang.org/std/env/consts/index.html 51 | - Can't if you want cross-compilation 52 | - Signing 53 | - debian: on the repo 54 | - windows: embedded in the exe 55 | - mac: in a paralel file or extended attributes 56 | - Using extended attributes can be lost when tarballing for transfer 57 | - Knowing the multiarch triplet for Ubuntu 58 | - See [`cargo-deb`'s workaround](https://github.com/mmstick/cargo-deb/blob/master/src/manifest.rs#L697) 59 | - ARM is where this can get weird 60 | - `std::env::ARCH` is ambiguous 61 | - Identifying the target triplet 62 | - Not returned by `cargo-metadata` 63 | - Not available as an env variable when compiling the program 64 | - Workaround: [use a build script](https://github.com/mmstick/cargo-deb/blob/master/build.rs) 65 | - Note: that is used for identifying the default target triplet, can be overridden on the command line 66 | - Desire for a crate generating multiple packages 67 | - Linux packages: arch vs noarch 68 | - `-dbg` packages, see https://github.com/mmstick/cargo-deb/issues/62 69 | - A workspace might want to be a single package or a package per type of artifact 70 | 71 | ## Stager 72 | 73 | Grand vision: All packaging tools use the same configuration schema; data and 74 | fields are just specialized to the individual distribution needs 75 | 76 | Ways to accomplish this 77 | - Tiered configuration 78 | - `cargo-deb` would read from its own section of configuration, falling back to a general config for unspecified fields 79 | - `Cargo.toml` already provides a lot of what the general config could be 80 | - Common, consistent patterns for 81 | - workspaces 82 | - defining multiple top-level packages (ignoring `-dbg` and so on) 83 | - Common format for describing layout of files along with metadata, like permissions, and where the files can be sourced from 84 | - Introducing [`stager`](https://github.com/crate-ci/stager) 85 | 86 | 87 | Or put another way, a Rust ecosystem equivalent of [sbt native packager](https://sbt-native-packager.readthedocs.io/en/stable/) 88 | 89 | Example client: [`cargo-tarball`](https://github.com/crate-ci/cargo-tarball) which is meant to replace `trust` boilerplate. 90 | 91 | Status 92 | - stager: ready for integration into packaging tools to identify missing features 93 | - cargo-tarball: Almost self-releasing, just missing a few features 94 | 95 | ### What is stager 96 | 97 | Stager defines a common format for describing how to layout files in a package 98 | and provides the tools to make this happen. 99 | 100 | At the moment, the format leverages the [liquid template 101 | language](https://shopify.github.io/liquid/) for making life easier for stager 102 | dependents on their users. 103 | 104 | Currently, all of the data is staged into a directory. This could evolve 105 | to support in-memory staging where files are directly written to compressed files. 106 | 107 | ### Open Issues 108 | 109 | #### Packaging configuration home 110 | 111 | Should we put this packaging configuration inside a `Cargo.toml` `[metadata]` table or in a separate file? 112 | 113 | #### Auto-generate binary artifacts 114 | 115 | Create cargo source for stager to run cargo and generate the binary to then stage. 116 | 117 | #### Compression 118 | 119 | For `deb`, documentation should be compressed. 120 | - Created [crate-ci/stager#18](https://github.com/crate-ci/stager/issues/18) in response 121 | - cargo-deb wants to abstract these rules 122 | - This policy can't live in stager 123 | - Will need to walk the staging configuration, identifying documentation, and mutate them to enable compression. 124 | -------------------------------------------------------------------------------- /survey-results/Readme.md: -------------------------------------------------------------------------------- 1 | # Rust CLI Survey 2 | 3 | Over the month of March 2018, we've been accepting responses to the Rust CLI Survey. This survey was designed to give us some areas of focus, according to the community, for the [CLI Working Group](https://github.com/rust-lang-nursery/cli-wg) (CLI-WG). 4 | 5 | One of the goals of Rust 2018 is to make writing command line applications in Rust as frictionless (and fun!) as possible. And we are super excited to say: we've received 1,045 responses! The results, while varied, paint a pretty clear picture for tangible goals. 6 | 7 | Because the CLI-WG is relatively small, unfortunately we cannot address all concerns raised in this survey. But with posts like this one, we hope to raise some awareness into what the community is collectively looking for, and things that you can use in your own crates and projects. 8 | 9 | We will also be using these results to guide our solutions when conducting any official reviews, or contributions as part of the CLI-WG. 10 | 11 | Before we dig in to the results, let's first define a CLI, [according to the working group](https://github.com/rust-lang-nursery/cli-wg/issues/4), in order to properly limit the scope. 12 | 13 | > For our intents and purposes, a CLI is any program that 14 | > 15 | > * Launches in a terminal 16 | > * Accepts configuration from various sources, such as command line arguments, environment variables, or configuration files 17 | > * Runs to completion with minimal/no user interaction 18 | > * Accepts input from stdin, files, or network 19 | > * Performs processing on some input (files, network, stdin) based on the configuration specified 20 | > * Communicates via standard outputs (files, network, std{out,err}) 21 | > 22 | > (We specifically don't want to focus on "TUI" apps right now.) 23 | 24 | This may not be an all encompassing definition, but it's what we're using for the time being in order to limit the scope. Some (even many) survey respondents did comment on TUIs (i.e., programs that present an interactive command line interface, like `vim` or `top`), so we want to say that we acknowledge the gap, and may look to assist with this in the future. But for the time being we are calling that "out of scope" for this working group (with too large a scope we may never accomplish anything!). 25 | 26 | With that out of the way, let's walk through some of the responses, and what we're doing with the results. 27 | 28 | ## Responses 29 | 30 | Starting with the demographics, it was surprising (and extremely appreciated) that around 44% of survey respondents have been using Rust for less than a year, or haven't used Rust at all! This great because it gives us "fresh eyes" to see issues that long time Rustaceans may gloss over because they've resolved it (or found a work-around) long ago. However, these issues not only hurt adoption, but create needless friction that could be smoothed over. 31 | 32 | Likewise, about 33% of respondents said they had not ever, or currently are not, writing a CLI application in Rust. We used this info to see any specific friction points that may be preventing people who may not have spent much time digging through crates/documentation, etc. 33 | 34 | [![Bar chart about since when people have been using Rust](rust-user-since.svg)](rust-user-since.svg) 35 | 36 | ### Crates in Use 37 | 38 | Of the people that responded as having had written (or are currently writing) a CLI application in Rust (approximately 588 responses) we asked what current crates they are using. This gave us a great list of common libraries, or areas we can focus on polishing APIs and improving the overall documentation and guides. This list also shows some rather unknown crates that have *tons* of potential. We won't list all crates here as the list is quite long, but it will greatly help the CLI-WG in determining where to focus efforts. 39 | 40 | The word cloud ended up looking like this (link contains higher resolution image): 41 | 42 | [![Bubble chart showing most used crates](crates.svg)](crates.svg) 43 | 44 | ### Where to Improve 45 | 46 | We then asked what areas these crates could use the most improvement. The resounding answer (and repeated throughout the survey) is more comprehensive documentation, tutorials, and guides/examples. Requests for better documentation and examples made up over half of the responses to this question, with 45% and 57% respectively! 47 | 48 | [![Bar chart showing areas of where to improve](what-to-improve.svg)](what-to-improve.svg) 49 | 50 | Many times throughout the survey there were responses requesting the ability to do a thing, when there is in fact an excellent crate already available for that thing. There were also many responses where certain features were requested of particular named crates, when that feature already exists in said crate. 51 | 52 | This just re-enforces the need in our mind for better documentation and examples. I plan on revisiting the documentation and examples for my own crates because of these responses. 53 | 54 | The CLI-WG has a list of "Tracking Issues" in our repository for discussing solutions and problems related to the working group. Because of the survey, we've opened up more issues to address concerns raised. 55 | 56 | For this first section we've opened two issues: 57 | 58 | * [The "ideal guide" for writing CLI apps in Rust · Issue #6 · rust-lang-nursery/cli-wg · GitHub](https://github.com/rust-lang-nursery/cli-wg/issues/6)) 59 | * [Improve ecosystem discoverability · Issue #11 · rust-lang-nursery/cli-wg · GitHub](https://github.com/rust-lang-nursery/cli-wg/issues/11) 60 | 61 | Examples and Documentation will also be key areas of focus when contributing or maintaining crates. 62 | 63 | Platform Availability was in second place (with ~14%), hence we're determined to consider the big three platforms (Linux, Windows, and macOS) while discussing and creating any official solutions, or reviews from the CLI-WG. 64 | 65 | ### Existing Gaps 66 | 67 | Next we asked what are the current gaps in the ecosystem when working on CLI applications, and what the respondent did about them. The results can be summed up into these bullets (not necessarily in order): 68 | 69 | * Better guides/examples for CLI application structure 70 | * (Cross Platform) Configuration File Management 71 | * Better ergonomics of merging various levels of configs (global, project, CLI flags) 72 | * Better ergonomics of File Paths 73 | * Release/Packaging guides/examples 74 | * More Docs/Tooling around Binary Releases 75 | * Clean readline implementation, problems with each current offering 76 | * Standardize generation / installation of manpages 77 | * Better CLI testing 78 | * Terminal Coloring (esp. Windows) 79 | * Better logging (or decrease current complexities) 80 | * Better documentation of crates 81 | * More libs to 1.0 82 | * Improve Error Handling 83 | * Discover ability of crates 84 | 85 | The raw word cloud looks like this (link contains higher resolution image): 86 | 87 | [![Bubble chart showing gaps in the ecosystem](gaps.svg)](gaps.svg) 88 | 89 | Note that word cloud contains a mixture of existing gaps, what respondents did, etc. But it still paints an accurate picture of what's happening in the Rust ecosystem *today*. 90 | 91 | To begin to address some of these areas we've opened the following issues: 92 | 93 | * [Config file management · Issue #7 · rust-lang-nursery/cli-wg · GitHub](https://github.com/rust-lang-nursery/cli-wg/issues/7) 94 | * [Testing CLI apps · Issue #9 · rust-lang-nursery/cli-wg · GitHub](https://github.com/rust-lang-nursery/cli-wg/issues/9) 95 | * [Cross-platform file system abstractions · Issue #10 · rust-lang-nursery/cli-wg · GitHub](https://github.com/rust-lang-nursery/cli-wg/issues/10) 96 | * [Embrace Standardized Color Control · Issue #15 · rust-lang-nursery/cli-wg · GitHub](https://github.com/rust-lang-nursery/cli-wg/issues/15) 97 | * [Documenting CLIs · Issue #23 · rust-lang-nursery/cli-wg · GitHub](https://github.com/rust-lang-nursery/cli-wg/issues/23) 98 | * [Error handling in CLI apps · Issue #12 · rust-lang-nursery/cli-wg · GitHub](https://github.com/rust-lang-nursery/cli-wg/issues/12) 99 | * [Improve ecosystem discoverability · Issue #11 · rust-lang-nursery/cli-wg · GitHub](https://github.com/rust-lang-nursery/cli-wg/issues/11) 100 | 101 | It also appeared to be a common theme that people simply wanted to know, "What crate should I [at least start with] to do `X`?" As at times there are many crates with similar goals that appear to be competing. While I don't believe the Rust team wants to "bless" particular crates as that makes it arbitrarily hard for newcomers that are actually better to "dethrone" any currently widely used crates, we *can* do a better job at making it clearly visible which crates are actively maintained and widely used. This is somewhat orthogonal to the CLI-WG's goals, as it crosses over into recent work being done by the crates.io team, but it's still something we want to consider and work towards at all ends. 102 | 103 | A key part of this from the CLI-WG's perspective is more guides/tutorials on how to do tasks, and write CLIs using proven third party crates will naturally increase awareness of which particular crates have at least been "battle tested." 104 | 105 | ## After the Build 106 | 107 | We wanted to know what people do after they've built the CLI application. What platforms they target, how they release, etc. These responses are helping us shape which areas will be the focus going forward. 108 | 109 | ### Platform Targets 110 | 111 | [![Bar chart of package managers or platforms targeted](packaging.svg)](packaging.svg) 112 | 113 | First, we asked which platforms people target, the results came across like so: 114 | 115 | * Linux (92% - 662 responses) 116 | * macOS (53% - 365 responses) 117 | * Windows (40% - 278 responses) 118 | * BSD Variants (12% - 85 responses) 119 | * Embedded (7% - 47 responses) 120 | 121 | This is unsurprising, but still great information as it shows just frequently people target Windows for CLI applications. I'm just as guilty of treating Windows as a second class citizen myself, and thus after this survey a personal goal of mine is to improve my Windows support! 122 | 123 | ### Platform Specific Issues 124 | 125 | We asked if there were any platform specific issues (some of which we were already aware of), and again the result quite clear! Windows support is clearly lacking in the ecosystem, this includes terminal color support, path handling, configuration file handling, etc. Here is a summarized list of the reoccurring themes: 126 | 127 | * Windows support!!! 128 | * Coloring 129 | * Paths 130 | * Configs 131 | * Need more crates that expose platform specific features 132 | * Cross compiling is still complicated 133 | * `OsStr`/`OsString` 134 | * Inconsistencies when compared to `&str`/`String` 135 | * Ergonomics of use 136 | * General confusion 137 | * How to specify platform specific deps 138 | * Lack of good Signal Handling crate 139 | 140 | Some of these have been actively worked on prior to the CLI-WG such as [@BurntSushi's](https://github.com/BurntSushi) excellent [`termcolor`](https://crates.io/crates/termcolor) crate which was specifically designed with cross platform terminal color support. But this goes back to the discover-ability issue mentioned above. 141 | 142 | To assist with the above bullets, we've opened the following issues: 143 | 144 | * [Embrace Standardized Color Control · Issue #15 · rust-lang-nursery/cli-wg · GitHub](https://github.com/rust-lang-nursery/cli-wg/issues/15) 145 | * [Improve ecosystem discoverability · Issue #11 · rust-lang-nursery/cli-wg · GitHub](https://github.com/rust-lang-nursery/cli-wg/issues/11) 146 | * [Ergonomics of Cross Compiling · Issue #25 · rust-lang-nursery/cli-wg · GitHub](https://github.com/rust-lang-nursery/cli-wg/issues/25) 147 | * [Ergonomics of String handling · Issue #26 · rust-lang-nursery/cli-wg · GitHub](https://github.com/rust-lang-nursery/cli-wg/issues/26) 148 | * [Cross-platform file system abstractions · Issue #10 · rust-lang-nursery/cli-wg · GitHub](https://github.com/rust-lang-nursery/cli-wg/issues/10) 149 | * * [Signal handling · Issue #27 · rust-lang-nursery/cli-wg · GitHub](https://github.com/rust-lang-nursery/cli-wg/issues/27) 150 | 151 | ### Distribution 152 | 153 | Finally, we wanted to know how people were getting their CLI applications out to the rest of the world. By far, the two largest methods were crates.io and `cargo install` along with plain old zipped (or `tar.gz`'ed) binaries. 154 | 155 | This points to a major area of focus for us, because `cargo install` wasn't originally designed to handle large scale distribution of end user applications (see [this issue comment from me](https://github.com/rust-lang-nursery/cli-wg/issues/8#issuecomment-370565293)). To be fair, we did not ask people to distinguish between "Rust Developer" focused applications, or "General Purpose" applications (`cargo install` was *absolutely* designed to easily distribute tools meant for use in Rust development). So we're working through ways to decrease the friction when using other, perhaps more appropriate methods of distribution while at the same time increase the experience using `cargo install` for Rust development tools. 156 | 157 | We've opened the following issues to address packaging and distribution: 158 | 159 | * [Packaging and distributing apps · Issue #8 · rust-lang-nursery/cli-wg · GitHub](https://github.com/rust-lang-nursery/cli-wg/issues/8) 160 | * [Improving binary distribution through cargo. · Issue #20 · rust-lang-nursery/cli-wg · GitHub](https://github.com/rust-lang-nursery/cli-wg/issues/20) 161 | * [Support development of well-behaved CLI apps · Issue #21 · rust-lang-nursery/cli-wg · GitHub](https://github.com/rust-lang-nursery/cli-wg/issues/21) 162 | 163 | The other more complete list of distribution methods selected was (number of responses is approximate): 164 | 165 | * crates.io / `cargo install` (58% - 288 responses) 166 | * Zipped binary (51% - 257 responses) 167 | * Native Linux Repos (27% - 135 responses) 168 | * Homebrew (9% - 46 responses) 169 | * Linux snap/flatpak/AppImage (6% - 31 responses) 170 | * Docker (2% - 10 responses) 171 | * Windows Chocolatey (2% - 9 responses) 172 | 173 | ## Compared to Other Languages 174 | 175 | People who have been using Rust, we asked for their reasons to pick it as the language for their CLI app. And we are happy to say that most people are really enjoying the language itself! We can all agree that this is a very solid reason. Close second is Cargo and the crates ecosystem, as well as runtime performance. 176 | 177 | It's interesting to see that not very many people said that the documentation, safety, or static binaries were things that sold them on Rust -- which we assume is partially because the competition here is pretty tough, but also because we can do better in these areas (as the Where to Improve section also mentions). 178 | 179 | [![Bar chart showing reasons to use Rust for CLI apps](why-rust.svg)](why-rust.svg) 180 | 181 | We also asked survey respondents if they'd ever used other languages to write CLI applications along with what Rust could learn from the experience using those languages. 182 | 183 | Python took the far lead. The top languages were: 184 | 185 | * Python 56% (516 responses) 186 | * C/C++ 26% (237 responses) 187 | * Go 14% (128 responses) 188 | * Ruby 13% (116 responses) 189 | * Bash 11% (100 responses) 190 | 191 | There were many other languages as well, but the numbers started quickly dropping off after the above. Here's the word cloud (link contains higher resolution image): 192 | 193 | [![Bubble chart showing other languages](languages.svg)](languages.svg) 194 | 195 | ### What Can we Learn? 196 | 197 | Having the above numbers, we also asked what those languages do *better* than Rust, and what we could learn from them. 198 | 199 | Overwhelmingly there seemed to be two common themes: 200 | 201 | * Rapid Prototyping / Development speed (Coming from Python/Ruby) 202 | * More comprehensive "frameworks" (coming from Ruby, but also some from Python) 203 | 204 | While some of the decrease in rapid prototyping and development speed is natural from using a statically typed compiled language, as opposed to something like Python or Ruby it's still an issue we care about. We want to make it just as easy to whip up a tiny script in Rust as it is in Python or Ruby (or at least that's the goal we're moving towards). 205 | 206 | Another aspect of developer speed is improving the ergonomics around small things like Strings and File Paths. Which brings me to the other less frequent, but still important themes were: 207 | 208 | * More Examples 209 | * More Guides/Tooling on Releasing 210 | * Compile Times 211 | * Better ergonomics of string handling 212 | 213 | To address the above bullets we've opened: 214 | 215 | * [Ergonomics of String handling · Issue #26 · rust-lang-nursery/cli-wg · GitHub](https://github.com/rust-lang-nursery/cli-wg/issues/26) 216 | * [Cross-platform file system abstractions · Issue #10 · rust-lang-nursery/cli-wg · GitHub](https://github.com/rust-lang-nursery/cli-wg/issues/10) 217 | * [Packaging and distributing apps · Issue #8 · rust-lang-nursery/cli-wg · GitHub](https://github.com/rust-lang-nursery/cli-wg/issues/8) 218 | * [The "ideal guide" for writing CLI apps in Rust · Issue #6 · rust-lang-nursery/cli-wg · GitHub](https://github.com/rust-lang-nursery/cli-wg/issues/6) 219 | 220 | The other bullets are well known, such as compile times, and being actively worked on by other Teams. 221 | 222 | *As an aside, many respondents said Rust was already doing great things in the CLI space compared to other languages (♥).* 223 | 224 | ## Anything else? 225 | 226 | As a parting question, we asked survey respondents if there was anything else they'd like to tell us. Again, some common themes popped up. Most summarizing what has already been listed above, but here are few key points. 227 | 228 | * `const fn` / `constexpr` please! 229 | * `impl Trait` please! 230 | * Post build steps in `cargo` are needed 231 | * Need more work towards 1.0 crates 232 | * Need way to auto-generate manpages 233 | 234 | As mentioned above, [`miri` was recently merged into `rustc`](https://github.com/rust-lang/rust/pull/46882) which makes significant progress towards `constfn` / `constexpr`! Also, [`impl Trait` was recently `r+`'ed](https://github.com/rust-lang/rust/pull/49255#issuecomment-375368749)! That's almost two points right away! 235 | 236 | Some issues to address the above points are: 237 | 238 | * [Tracker of Issues in Other Crates · Issue #14 · rust-lang-nursery/cli-wg · GitHub](https://github.com/rust-lang-nursery/cli-wg/issues/14) 239 | * [Documenting CLIs · Issue #23 · rust-lang-nursery/cli-wg · GitHub](https://github.com/rust-lang-nursery/cli-wg/issues/23) (for manpage generation) 240 | * [Add an install.rs that lets a file perform installation setup, as well as a permanent installation outdir · Issue #2386 · rust-lang/cargo · GitHub](https://github.com/rust-lang/cargo/issues/2386) 241 | 242 | # What Now 243 | 244 | Many people throughout the survey also requested more standardization between various crates and methodologies. Although we don't specifically call it out above, we wanted to say that it's something we're aware of and working towards as a sort to of overarching meta goal. 245 | 246 | One example of moving towards this goal; [`clap`](https://github.com/kbknapp/clap-rs) and [`structopt`](https://github.com/TeXitoi/structopt) will be merging in the near future with the `clap` v3 release. `structopt` is a Custom Derive wrapper around `clap` and it was pretty clear form the survey that having the two separate increases the confusion between them, even though they use the same code underneath. This should be one small step towards rectifying perceived divides in the ecosystem. 247 | 248 | There are also projects like [`ergo`](https://github.com/rust-crates/ergo) (and it's various sub-crates) which are still in pre-alpha stages but that aim to provide unified experiences when working with many of the sub-domains that CLI applications touch. 249 | 250 | Towards the goal: 251 | 252 | > Writing a one-off small script in Rust should be as pleasant and easy as it is today in Python, Ruby, or Bash 253 | 254 | [@killercup (Pascal Hertleif, the CLI-WG lead)](https://github.com/killercup) is working on [`quicli`](https://github.com/killercup/quicli) (pronounced "quickly" and is a play on "Quick CLI") for just such a use. It's aim is to leverage existing CLI crates while removing all the Rust boilerplate in order to quickly get small scripts and utilities out the door. Like `ergo`, it's still early days, but very usuable already! 255 | 256 | ## Call to Action! 257 | 258 | With the survey complete the work is just beginning. We'd love participation in the linked issues above throughout this post, or of course feel free to open new issues if your concern isn't being heard. 259 | 260 | Now is the time to voice the details so that we can begin to work towards a more frictionless CLI experience in Rust! From the survey there are a few concrete actions everyone can take to instantly improve the ecosystem: 261 | 262 | 1. Write about your crates. 263 | 2. Review the documentation 264 | 3. Consider Windows as a target 265 | 4. Create/Comment on Issues 266 | 267 | Let me elaborate very quickly. 268 | 269 | ### Write about your crates 270 | 271 | People are craving examples! If you already have beginner examples, try adding a more comprehensive and complete example. Any medium works, blogs, Rustdoc API examples, examples directories in the project repository, etc. 272 | 273 | Make sure to link to these examples from somewhere in your project. If people can't find the examples, they can't enjoy them! 274 | 275 | If you don't have time to write the examples, open issues requesting examples, or drop a request in the weekly Call for Participation section of [This Week in Rust](https://this-week-in-rust.org/). There were numerous replies to the survey saying people would like to contribute but don't know where to start! This is a perfect place! 276 | 277 | ### Review the Documentation 278 | 279 | If you already have API docs, have someone else take a quick look at them and give feedback. As the author of a crate, it's very simple to be so accustomed to how something is working, that the API docs end up lacking for someone who isn't at intimately familiar with them as the author. 280 | 281 | Again, opening issues requesting docs reviews is a perfect way to get new eyes on the project and get feedback! 282 | 283 | ### Consider Windows as first class target 284 | 285 | There are many Windows users out there, and making your CLI application work the same for them as it does for a macOS or Linux user is such a big accomplishment. With Rust, it's often somewhat trivial to ensure the experience is the same crossplatform. Of course there are edge cases like terminal color and the like, but that is something we hope to rectify over the coming months. 286 | 287 | At the very least, requesting Windows maintainers, or running your code on free CI providers that have Windows support, like [AppVeyor](https://www.appveyor.com/), can make a tremendous difference! 288 | 289 | ### Create and/or Comment on Issues 290 | 291 | The survey pointed out that there are many small issues with crates in our ecosystem. Some pointed to issues in my own crates, which I had no idea about! Instead of struggling in silence, I'd have wished these people would have pinged me in a Github issue, or irc, or discord, or even email! I love helping people out, but if I don't know about something I can't help. 292 | 293 | Creating and commenting on issues (both in your own repositories and of the crates you use) is a *HUGE* help. 294 | 295 | Speaking to people in person I often hear phrases like, "Meh, it was just a minor issue, I didn't want to burden the project with that!" or "I'm *sure* they already know about `x`!", or the worse, "I don't want to embarrass them by publicly list the issue!" 296 | 297 | Please, *please* if you see an issue, or have a question contact the crate team. Each project will be a little different, but whether it's an issue, irc, discord, whatever, I can almost certainly say the project will be thankful for the contribution. 298 | 299 | ## What the Working Group Will Do 300 | 301 | Our current mission can be summarized as: 302 | 303 | - Help improve existing crates. 304 | - Consolidate existing solutions and create "best practice" crates. 305 | 306 | While the first point is about making existing crates better – by applying what we've laid out above – the second point is about getting towards a set of easy to find and easy to use solutions for some of the gaps that were mentioned. For example, we need an ergonomic cross-platform terminal color crate that a lot of people can _just use_, in contrast to being overwhelmed by the existing 10 solutions whose feature support is not easy to compare. 307 | 308 | We've already mentioned some of the projects, but we'll keep you updated on more in our newsletter. (If you want to be even more up-to-date on our efforts, join our [Discord channel](https://discord.gg/dwq4Zme) where we discuss this!) 309 | 310 | # Thank you! 311 | 312 | With this said, we want to thank all respondents and those that have been working away at the listed issues, Discord chat, and assisting us in so many shapes and fashions! 313 | 314 | The CLI-WG also has a [Discord channel](https://discord.gg/dwq4Zme) that is open everyone who wishes to contribute. All of the issues opened on [the CLI-WG repository](https://github.com/rust-lang-nursery/cli-wg) are open for comments if you have opinions on these matters. 315 | 316 | One final time, thank you so much to all the over 1,000 respondents! 317 | 318 | Stay tuned for CLI-WG newsletters and updates in the coming weeks and months! -------------------------------------------------------------------------------- /survey-results/gaps.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | platform specific 9 | 10 | platform specific,7 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | wrote it myself 19 | 20 | wrote it myself,19 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | ipc 29 | 30 | ipc,1 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | xml 39 | 40 | xml,2 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | standard paths 49 | 50 | standard paths,1 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | packaging 59 | 60 | packaging,1 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | paths 69 | 70 | paths,5 71 | 72 | 73 | 74 | 75 | 76 | 77 | 78 | config files 79 | 80 | config files,18 81 | 82 | 83 | 84 | 85 | 86 | 87 | 88 | streaming 89 | 90 | streaming,3 91 | 92 | 93 | 94 | 95 | 96 | 97 | 98 | errors 99 | 100 | errors,6 101 | 102 | 103 | 104 | 105 | 106 | 107 | 108 | http 109 | 110 | http,7 111 | 112 | 113 | 114 | 115 | 116 | 117 | 118 | ide 119 | 120 | ide,1 121 | 122 | 123 | 124 | 125 | 126 | 127 | 128 | cross platform 129 | 130 | cross platform,9 131 | 132 | 133 | 134 | 135 | 136 | 137 | 138 | gui 139 | 140 | gui,2 141 | 142 | 143 | 144 | 145 | 146 | 147 | 148 | games 149 | 150 | games,1 151 | 152 | 153 | 154 | 155 | 156 | 157 | 158 | unstable features 159 | 160 | unstable features,1 161 | 162 | 163 | 164 | 165 | 166 | 167 | 168 | guides 169 | 170 | guides,1 171 | 172 | 173 | 174 | 175 | 176 | 177 | 178 | domain specific 179 | 180 | domain specific,1 181 | 182 | 183 | 184 | 185 | 186 | 187 | 188 | wrote pr 189 | 190 | wrote pr,1 191 | 192 | 193 | 194 | 195 | 196 | 197 | 198 | interactive clis 199 | 200 | interactive clis,2 201 | 202 | 203 | 204 | 205 | 206 | 207 | 208 | stream files 209 | 210 | stream files,1 211 | 212 | 213 | 214 | 215 | 216 | 217 | 218 | term escape codes 219 | 220 | term escape codes,1 221 | 222 | 223 | 224 | 225 | 226 | 227 | 228 | parsing inputs 229 | 230 | parsing inputs,1 231 | 232 | 233 | 234 | 235 | 236 | 237 | 238 | crate usage 239 | 240 | crate usage,2 241 | 242 | 243 | 244 | 245 | 246 | 247 | 248 | tui 249 | 250 | tui,16 251 | 252 | 253 | 254 | 255 | 256 | 257 | 258 | readline 259 | 260 | readline,4 261 | 262 | 263 | 264 | 265 | 266 | 267 | 268 | feature bloat 269 | 270 | feature bloat,1 271 | 272 | 273 | 274 | 275 | 276 | 277 | 278 | signals 279 | 280 | signals,6 281 | 282 | 283 | 284 | 285 | 286 | 287 | 288 | ide support 289 | 290 | ide support,1 291 | 292 | 293 | 294 | 295 | 296 | 297 | 298 | use atom 299 | 300 | use atom,1 301 | 302 | 303 | 304 | 305 | 306 | 307 | 308 | pretty colored log output 309 | 310 | pretty colored log output,1 311 | 312 | 313 | 314 | 315 | 316 | 317 | 318 | async io 319 | 320 | async io,3 321 | 322 | 323 | 324 | 325 | 326 | 327 | 328 | man pages 329 | 330 | man pages,3 331 | 332 | 333 | 334 | 335 | 336 | 337 | 338 | testing 339 | 340 | testing,4 341 | 342 | 343 | 344 | 345 | 346 | 347 | 348 | pretty output 349 | 350 | pretty output,1 351 | 352 | 353 | 354 | 355 | 356 | 357 | 358 | colors 359 | 360 | colors,10 361 | 362 | 363 | 364 | 365 | 366 | 367 | 368 | opened a pr 369 | 370 | opened a pr,4 371 | 372 | 373 | 374 | 375 | 376 | 377 | 378 | parsing data formats 379 | 380 | parsing data formats,1 381 | 382 | 383 | 384 | 385 | 386 | 387 | 388 | 1 0 crates 389 | 390 | 1 0 crates,4 391 | 392 | 393 | 394 | 395 | 396 | 397 | 398 | credentials 399 | 400 | credentials,2 401 | 402 | 403 | 404 | 405 | 406 | 407 | 408 | autocompletion 409 | 410 | autocompletion,2 411 | 412 | 413 | 414 | 415 | 416 | 417 | 418 | crate discovery 419 | 420 | crate discovery,5 421 | 422 | 423 | 424 | 425 | 426 | 427 | 428 | web scraping 429 | 430 | web scraping,1 431 | 432 | 433 | 434 | 435 | 436 | 437 | 438 | glob 439 | 440 | glob,1 441 | 442 | 443 | 444 | 445 | 446 | 447 | 448 | logging 449 | 450 | logging,9 451 | 452 | 453 | 454 | 455 | 456 | 457 | 458 | tests 459 | 460 | tests,1 461 | 462 | 463 | 464 | 465 | 466 | 467 | 468 | open a pr 469 | 470 | open a pr,2 471 | 472 | 473 | 474 | 475 | 476 | 477 | 478 | ascii art 479 | 480 | ascii art,1 481 | 482 | 483 | 484 | 485 | 486 | 487 | 488 | exit code 489 | 490 | exit code,2 491 | 492 | 493 | 494 | 495 | 496 | 497 | 498 | rest apis 499 | 500 | rest apis,1 501 | 502 | 503 | 504 | 505 | 506 | 507 | 508 | windows 509 | 510 | windows,5 511 | 512 | 513 | 514 | 515 | 516 | 517 | 518 | cross paltform 519 | 520 | cross paltform,1 521 | 522 | 523 | 524 | 525 | 526 | 527 | 528 | terminal escapes 529 | 530 | terminal escapes,2 531 | 532 | 533 | 534 | 535 | 536 | 537 | 538 | fancy output 539 | 540 | fancy output,1 541 | 542 | 543 | 544 | 545 | 546 | 547 | 548 | fixed it myself 549 | 550 | fixed it myself,1 551 | 552 | 553 | 554 | 555 | 556 | 557 | 558 | structuring app code 559 | 560 | structuring app code,1 561 | 562 | 563 | 564 | 565 | 566 | 567 | 568 | no-std 569 | 570 | no-std,1 571 | 572 | 573 | 574 | 575 | 576 | 577 | 578 | terminal abstraction 579 | 580 | terminal abstraction,1 581 | 582 | 583 | 584 | 585 | 586 | 587 | 588 | pipes 589 | 590 | pipes,2 591 | 592 | 593 | 594 | 595 | 596 | 597 | 598 | all in one library 599 | 600 | all in one library,1 601 | 602 | 603 | 604 | 605 | 606 | 607 | 608 | best practices 609 | 610 | best practices,1 611 | 612 | 613 | 614 | 615 | 616 | 617 | 618 | localization 619 | 620 | localization,1 621 | 622 | 623 | 624 | 625 | 626 | 627 | 628 | translation 629 | 630 | translation,1 631 | 632 | 633 | 634 | 635 | 636 | 637 | 638 | more community maintained crates 639 | 640 | more community maintained crates,1 641 | 642 | 643 | 644 | 645 | 646 | 647 | 648 | packages 649 | 650 | packages,1 651 | 652 | 653 | 654 | 655 | 656 | 657 | 658 | parse input data 659 | 660 | parse input data,1 661 | 662 | 663 | 664 | 665 | 666 | 667 | 668 | cross compile 669 | 670 | cross compile,1 671 | 672 | 673 | 674 | 675 | 676 | 677 | 678 | sustainability 679 | 680 | sustainability,1 681 | 682 | 683 | 684 | 685 | 686 | 687 | 688 | config file 689 | 690 | config file,1 691 | 692 | 693 | 694 | 695 | 696 | 697 | 698 | crate features 699 | 700 | crate features,1 701 | 702 | 703 | 704 | 705 | 706 | 707 | 708 | translated docs 709 | 710 | translated docs,1 711 | 712 | 713 | 714 | 715 | 716 | 717 | 718 | lock files 719 | 720 | lock files,1 721 | 722 | 723 | 724 | 725 | 726 | 727 | 728 | system notifications 729 | 730 | system notifications,1 731 | 732 | 733 | 734 | 735 | 736 | 737 | 738 | standardized output 739 | 740 | standardized output,1 741 | 742 | 743 | 744 | 745 | 746 | 747 | 748 | gaming 749 | 750 | gaming,1 751 | 752 | 753 | 754 | 755 | 756 | 757 | 758 | parser generator 759 | 760 | parser generator,1 761 | 762 | 763 | 764 | 765 | 766 | 767 | 768 | consult community docs 769 | 770 | consult community docs,1 771 | 772 | 773 | 774 | 775 | 776 | 777 | 778 | process info 779 | 780 | process info,1 781 | 782 | 783 | 784 | 785 | 786 | 787 | 788 | binary bloat 789 | 790 | binary bloat,1 791 | 792 | 793 | 794 | 795 | 796 | 797 | 798 | in main 799 | 800 | in main,1 801 | 802 | 803 | 804 | 805 | 806 | 807 | 808 | templating 809 | 810 | templating,1 811 | 812 | 813 | 814 | 815 | 816 | 817 | 818 | magic 819 | 820 | magic,1 821 | 822 | 823 | 824 | 825 | 826 | 827 | 828 | filed issue 829 | 830 | filed issue,1 831 | 832 | -------------------------------------------------------------------------------- /survey-results/languages.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | python 9 | 10 | python,509 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | c 19 | 20 | c,232 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | perl 29 | 30 | perl,32 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | shell 39 | 40 | shell,115 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | go 49 | 50 | go,125 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | ruby 59 | 60 | ruby,113 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | js 69 | 70 | js,77 71 | 72 | 73 | 74 | 75 | 76 | 77 | 78 | lua 79 | 80 | lua,8 81 | 82 | 83 | 84 | 85 | 86 | 87 | 88 | java 89 | 90 | java,89 91 | 92 | 93 | 94 | 95 | 96 | 97 | 98 | haskell 99 | 100 | haskell,29 101 | 102 | 103 | 104 | 105 | 106 | 107 | 108 | rust 109 | 110 | rust,29 111 | 112 | 113 | 114 | 115 | 116 | 117 | 118 | c++ 119 | 120 | c++,163 121 | 122 | 123 | 124 | 125 | 126 | 127 | 128 | clojure 129 | 130 | clojure,2 131 | 132 | 133 | 134 | 135 | 136 | 137 | 138 | c c++ 139 | 140 | c c++,8 141 | 142 | 143 | 144 | 145 | 146 | 147 | 148 | php 149 | 150 | php,25 151 | 152 | 153 | 154 | 155 | 156 | 157 | 158 | kotlin 159 | 160 | kotlin,6 161 | 162 | 163 | 164 | 165 | 166 | 167 | 168 | fortran 169 | 170 | fortran,3 171 | 172 | 173 | 174 | 175 | 176 | 177 | 178 | powershell 179 | 180 | powershell,3 181 | 182 | 183 | 184 | 185 | 186 | 187 | 188 | erlang 189 | 190 | erlang,3 191 | 192 | 193 | 194 | 195 | 196 | 197 | 198 | elixir 199 | 200 | elixir,5 201 | 202 | 203 | 204 | 205 | 206 | 207 | 208 | swift 209 | 210 | swift,5 211 | 212 | 213 | 214 | 215 | 216 | 217 | 218 | coffeescript 219 | 220 | coffeescript,2 221 | 222 | 223 | 224 | 225 | 226 | 227 | 228 | groovy 229 | 230 | groovy,3 231 | 232 | 233 | 234 | 235 | 236 | 237 | 238 | scala 239 | 240 | scala,16 241 | 242 | 243 | 244 | 245 | 246 | 247 | 248 | pascal 249 | 250 | pascal,3 251 | 252 | 253 | 254 | 255 | 256 | 257 | 258 | tcl 259 | 260 | tcl,3 261 | 262 | 263 | 264 | 265 | 266 | 267 | 268 | typescript 269 | 270 | typescript,5 271 | 272 | 273 | 274 | 275 | 276 | 277 | 278 | posix shell 279 | 280 | posix shell,2 281 | 282 | 283 | 284 | 285 | 286 | 287 | 288 | node 289 | 290 | node,11 291 | 292 | 293 | 294 | 295 | 296 | 297 | 298 | ocaml 299 | 300 | ocaml,3 301 | 302 | 303 | 304 | 305 | 306 | 307 | 308 | d 309 | 310 | d,4 311 | 312 | 313 | 314 | 315 | 316 | 317 | 318 | sh 319 | 320 | sh,2 321 | 322 | -------------------------------------------------------------------------------- /survey-results/packaging.svg: -------------------------------------------------------------------------------- 1 | 050100150200250300count.zipappimage (linux)aurchocolatey (windows)crates.io (and `cargo install`)dockerdocker imagedownloads: .tar.gzflatpakfreebsd portsgithubhomebrew (macos, linux)native linux repositoriessnap -------------------------------------------------------------------------------- /survey-results/platforms.svg: -------------------------------------------------------------------------------- 1 | 0100200300400500600700countandroidbsd variant(s)embeddedlinuxmacosredoxwindows -------------------------------------------------------------------------------- /survey-results/rust-user-since.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 0 41 | 100 42 | 200 43 | 300 44 | 400 45 | 46 | 47 | 48 | 49 | 50 | Number of Records 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 1-2 years 68 | 3-5 years 69 | Forever 70 | I don't currently use Rust 71 | Less than a year 72 | 73 | 74 | 75 | 76 | 77 | 78 | 79 | 80 | 81 | 82 | 83 | -------------------------------------------------------------------------------- /survey-results/what-to-improve.svg: -------------------------------------------------------------------------------- 1 | 050100150200250countbinary bloatcompile timesdocumentationergonomicsexamplesfeaturesmaintenancematurityplatform availabilitytestingwork with no_std -------------------------------------------------------------------------------- /survey-results/why-rust.svg: -------------------------------------------------------------------------------- 1 | 0100200300400500600countcargo/build systemcicrates/ecosystemdocumentation/guidesease of distributionlearning rustruntime performancerust language itselfsafetystatic binariestestingthe app was already written in rust wh… --------------------------------------------------------------------------------