From fd6b07ac8a940518b8c8bf69e19d3fd345cb7344 Mon Sep 17 00:00:00 2001 From: Yoshua Wuyts Date: Tue, 20 Feb 2018 19:17:44 +0100 Subject: [PATCH] first meeting notes --- logs/2018-02-20-cli-wg-initial-meeting.log | 328 +++++++++++++++++++++ 1 file changed, 328 insertions(+) create mode 100644 logs/2018-02-20-cli-wg-initial-meeting.log diff --git a/logs/2018-02-20-cli-wg-initial-meeting.log b/logs/2018-02-20-cli-wg-initial-meeting.log new file mode 100644 index 00000000..927da2ce --- /dev/null +++ b/logs/2018-02-20-cli-wg-initial-meeting.log @@ -0,0 +1,328 @@ +18:00 hey @/all, welcome to the first CLI working group meeting! +18:00 This meeting about the goals and format of the working group +18:00 It is not about concrete details, I want to keep it focused on big picture for now +18:01 The time box is an hour (let's see if I manage to keep us on schedule) +18:01 o/ +18:01 o/ +18:01 hi! +18:02 first of all, thank you all for showing up! +18:02 and for discussion so much stuff already! +18:02 hi All :) +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 +18:04 i want to go through the "goals" for a bit +18:04 > - Rust is known to be a very good language for writing CLI tools +18:04 > - "Writing a CLI tool" is a good way to get started with Rust as a beginner +18:04 > - Make it easy to ship well-tested binaries +18:04 > - "Writing seamless binaries in Rust should be effortless" +18:04 does anyone want to add something to that list? +18:04 or, even better, want to compress some of the points into a new one? :) +18:05 how about "work effectively the same on all platforms"? +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 +18:05 Agreed. +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"? +18:06 yeh +18:06 → dherman joined (dherman@irc.gitter.im) +18:07 as in the user doesn't have to bother about different platforms +18:07 that's a pretty cool goal! +18:07 cool. that's really ambitious, though! +18:07 Seems like some of the high level ideas +18:07 - Fun / low friction +18:07 - Cross-platform +18:07 - End-user consumable (distribution) +18:07 - Releasing with confidence +18:08 Now how to capture that in a slogan :) +18:08 agreed. platform compatibility is a great goal +18:08 @dherman waves +18:08 that's a pretty good summary ^ +18:08 Very ambitious though +18:08 → jonathandturner joined (jonathandturner@irc.gitter.im) +18:08 great summary! +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 +18:08 @epage probably would add to that "Should feel native to the platform" +18:09 hi all, just thought I'd introduce myself -- I'm working on a new CLI tool (for Node) in Rust, and definitely interested in what this WG works on +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) +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 +18:09 ..., file path handling +18:09 there are a few Windows gotchas as well +18:10 @dherman you can present yourself in the etherpad in the topic +18:10 ok! +18:10 these all sounds like very concrete things we could work on! +18:10 @dherman hi! we'd be honored to have you join us :) can you add that to https://public.etherpad-mozilla.org/p/rust-cli-wg ? +18:10 :wave: Hey, joining now. Kinda thought it was in an hour :sweat_smile: +18:11 "timezones" :smile: +18:11 Time zones are fun, especially with day light saving +18:11 :sweat: +18:11 doodle save me the timezones issue :smile: +18:11 [edit] doodle saved me the timezones issue :smile: +18:11 I think it's more a problem of "my rubbish memory" :D +18:11 can we continue with the meeting? thanks :) +18:12 @killercup yeah, I like having that slogan as a base - and then expand with the list of @epage for more detail :D +18:12 so, i'm trying to come up with a sentence that covers this, something like "frictionless" and with "known best practices" +18:13 @killercup adding to the etherpad +18:13 @yoshuawuyts to be clear, my list was created to help us brainstorm parts to include in the slogan +18:13 gotcha! +18:14 killercup: sounds like "doing the right thing for reach platform should be straight forward" or something +18:14 "Frictionlessly creating CLIs with industry best practices"? +18:14 but then, nicer +18:15 "Writing CLI apps in Rust is a frictionless experience with known best practices that work across platforms, good documentation, and effortless distribution" +18:15 maybe a bit shorter :D +18:15 Those last to fall under frictionless to me +18:15 [edit] maybe make it a bit shorter :D +18:16 "writing cross-platform frictionless apps" +18:16 > "Frictionlessly creating CLIs with industry best practices”? +18:16 “Frictionlessly creating world class CLIs" +18:16 [edit] > "Frictionlessly creating CLIs with industry best practices”? +18:16 [edit] +18:16 [edit] “Frictionlessly creating world class CLIs" +18:16 "frictionless" is meant to describe the process, not the app +18:16 fair point +18:16 @epage yeah, i wanted to specify what is frictionless about it +18:17 don't mind having @killercup's version as a "working title" - can always revisit later +18:17 "Rust makes best-practice CLI applications frictionless through crates and documentation"? +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 +18:18 Sounds good +18:18 yah +18:18 +1 +18:18 cool, so, next point +19:18 what areas need out focus? +18:19 like, there are a lot of efforts to make writing CLI apps easier +18:19 where do we need to help out? +18:19 File management (cross platform stuff) +18:19 Especially for config files that would be great +18:19 @Eijebong like, dealing with paths or dealing with config files? +18:20 For linux under ~/.config, under Mac ~/Library (I think?), Windows…no idea +18:20 app packaging +18:20 is there any plan to make one crate that others can use and extend? +18:20 conglomeration crates / ecosystem discovery / API uniformity +18:20 maybe we should define CLI tools before +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) +18:20 `~/.config`, `~/.local`, `~/.cache` +18:21 @yoshuawuyts Plz respect `${XDG_*}`stuff :o +18:21 @TeXitoi Fair point, would a (n)curses tui count as a CLI? +18:21 @TeXitoi ah good point, how'd you define it? +18:21 Eijebong: haha, yeah yeah :p +18:22 :) +18:22 there is a crate for "determing system configuration" and it's apparently not as easy as it sounds +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 +18:22 So speaking of where the files are, the app_dirs crate exists. Is it a discovery issue, maturity issue, or something else? +18:22 but it is definitely something that should be solved +18:22 (thus ncurses is not in my definition) +18:22 @epage that's the one! +18:23 this one? https://github.com/AndyBarron/app-dirs-rs +18:23 it hasn't had an update and I heard from @BurntSushi that it is not maintained +18:23 (neither is daemons) +18:23 @TeXitoi good definition, and i think it's fair to start with this +18:25 (config files may or may not enter in my definition) +18:25 okay, so we have +18:25 +18:25 - dealing with configs +18:25 - packaging +18:25 - crate discovery +18:25 - testing cli apps (@dherman mentioned this earlier) +18:25 - error handling and user facing output +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 +18:26 How so? +18:26 Things like: absolute paths on Windows (UNC prefixes) +18:26 or: UTF-8 filenames on MacOS (the filesystem normalizes UTF-8 strings) +18:27 @TeXitoi +18:27 +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 +18:27 +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} +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 +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 +18:27 @sharkdp fd? +18:27 @sharkdp https://github.com/notion-cli/notion/blob/master/crates/verbatim/src/lib.rs +18:27 @sharkdp https://crates.io/crates/abs_path look like what you want? +18:28 @TeXitoi https://github.com/sharkdp/fd +18:29 @sharkdp thanks +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 +18:29 so is our main priority to build a master crate here? or fix existing issues everywhere? +18:30 @vitiral that's what we're here to do: create a good end-to-end story :) +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 +18:30 @Dylan-DPC It could probably be a mix of the two approaches. With good documentation where to find what +18:30 that brings us to the next point on my agenda that also let's me answer @Dylan-DPC question! +18:30 :) +18:30 how should we fix this? +18:31 (the "### How to get there" part of the etherpad) +18:31 @vitiral i know but my question was like "what should we focus more on". +18:31 probably part code, part guides, right? +18:32 i think a nice approach is trying to write an "ideal guide" +18:32 Part code, part guides, part tools to make life easier +18:32 to see where the holes are +18:32 That works +18:32 what do you mean by an "ideal guide"? +18:32 about focus - I think addressing universal issues would be a good start +18:33 issues that affect majority of CLI tools +18:33 yeah i agree +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 +18:33 Kind of like steve's 2018 blog post +18:33 cool! +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) +18:34 @killercup That sounds like a great idea +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` +18:34 yeah +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.) +18:35 @killercup where it downloads an "official" template of some kind from crates.io? +18:35 ← undefined left (undefined@irc.gitter.im) +18:36 @vitiral exactly, and that templates already contains a bunch of `extern crate foo;` and a good readme and ci setup for example +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 +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 +18:36 I have to run but I put some stuff in the etherpad. thanks all for getting this WG going! +18:36 ciao Dave :wave: +18:36 Bye +18:36 @dherman thanks for stopping by! +18:36 @killercup I like the idea of "official templates" regardless of other decisions :thumbsup: +18:37 @vitiral :+1: +18:37 `cargo new --template cli` and `ergo` aren't mutually exclusive either :D +18:37 +1 for templates +18:37 yap +18:37 maybe they could be distributed via rustup/cargo directly? +18:37 and you could also provide a github url or something? +18:38 let's not talk about the details for now, and the cargo folks probably already have some plans +18:38 okay, good point +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 +18:38 loops +18:38 @epage +1 I strongly agree with that +18:39 @epage +1 ya but i guess we need to provide some customisability as well +18:39 except it shouldn't lack platform neutrality +18:39 Well, @vitiral , we have already been talking about it :) +18:39 @epage yep, that's basically why i wrote quicli :) +18:39 process-wise we now need decide how do proceed +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 +18:39 @epage (ssh... they don't have to know :laughing:) +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 +18:40 @vitiral isn’t the “high level abstractions” what `ergo` somehow aims to provide. right? +18:40 @mattgathu yes +18:40 Someone should probably kickstart the "ideal guide" I reckon? +18:40 [edit] @mattgathu yes (edit: that is one of its goals) +18:40 So what do we need to discuss about the ideal guide or how do we get organized into writing it? +18:41 uhmm let's cover the broader topics first +18:41 personally I think the cookbook is a great place to start. How would the cookbook look in a perfect world? +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 +18:41 +1 +18:42 we have this repo: https://github.com/rust-lang-nursery/cli-wg +18:42 where i'll also post the logs of this meeting and the etherpad notes +18:42 @killercup do we have edit access/how should we open a repo, etc? +18:42 oh sorry, it's a single repo. I thought it was a group for second +18:43 just a single repo +18:43 a group wouldn't be a bad idea tbh +18:43 depends on how much stuff we want to do, i guess +18:43 You are all welcome to have editor access on rust-crates (which is the owner of ergo) +18:43 https://github.com/rust-crates/ +18:43 great +18:43 we can make any repos we want. Or we can use a different organization +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? +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? +18:44 @epage for example, yeah +18:45 @killercup I just made you full admin on rust-crates. I've been meaning to and forgot +18:45 yeah that's why i was suggesting an organisation +18:45 @epage or just discuss stuff in issues +18:45 the idea is to have a single repo where we can track stuff we are working on +18:45 and also talk about integration issues, and common efforts +18:45 @vitiral thanks! +18:45 sounds reasonable +18:46 btw when getting to implementation, `crate-ci` is possible home for relevant tools (like packaging) +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 +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 +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 +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_ +18:49 well, not "right now" right now, but "next" +18:49 And the rest of the doodle could be split up into multiple parts that are somewhat related. Makes it less monolithic +18:50 i think you all mean "etherpad" and not "the thing to find dates for meetings" +18:50 [edit] i think you all mean "etherpad" and not "the thing to find dates for meetings" ;) +18:50 Eh…yes +18:50 :P +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 :) +18:52 we can divide it into milestones and address certain issues in each milestone (preferably a quarter of the year) +18:52 I don't have any projects myself so I'd love to contribute wherever needed :P +18:52 @spacekookie lol, this is me too +18:52 perfect! that conveniently brings us to the next of my secret agenda for this meeting (that is totally not a post-it with "what, how, who, when")! +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")! +18:53 how should we do meetings? +18:53 like this? :P +18:54 that's one possibility, yeah +18:54 but more like, should we check in with each other every week? +18:54 biweekly? +18:54 Gitter is pretty convenient. Though if you stop reading for like 5 minutes it's super hard to catch up :joy: +18:54 yeah, think bi-weekly is a good one +18:54 haha true kat +18:54 Also, if we're breaking down into sub-groups, that'll help with catching up +18:54 every two weeks sounds good +18:54 yeah +18:55 sub groups could meet up every week +18:55 @epage :+1: Would we have different gitter channels then? +18:55 we can create rooms +18:55 Rooms seems reasonable. It'll make it easier to peek in on each other +18:55 @spacekookie feel free to create new ones, but i personally like how people lurking in a room can chime in and help ;) +18:56 As long as the meetings for the different groups aren't at the same time ;) +18:56 well you can be in 2 rooms at the same time ;) +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. +18:57 aye, agree +18:57 @Aaronepower I agree, nothing is more depressing than sitting in an empty room :frowning: +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. +18:57 :joy: +18:57 let's create new rooms lazily +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 +18:58 @Dylan-DPC Is that a bad thing? +18:58 it isn't. but it kinda defeats the purpose of a subgroup +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 :) +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 (: +18:59 yah yosh.. +18:59 Whew, just caught up on the messages :) +18:59 also multiple subgroups can't have a meeting at the same time unless they converge it into 1 +18:59 @kbknapp just in time! +18:59 @kbknapp impressive. I would have probably waited for the tl;dr +19:00 anyway it is not rocket science. we can figure it out lazilly +19:00 does anyone have any things they want to discuss this last minute? +19:00 Yeah but it being the first one, I wanted to follow along at least +19:00 @killercup so what's the road next? +19:00 [edit] @killercup so what's the plan next? +19:01 next up, we should all open issues on https://github.com/rust-lang-nursery/cli-wg ! +19:01 @killercup You haben't talked about the most important thing! Do we have a logo? :joy: +19:01 (Please ignore me) +19:01 :joy: +19:01 @spacekookie i now expect you to draw a logo as homework +19:01 Oh dear +19:01 :D Alright +19:02 i'll send out a doodle (the meeting time decider thing!) for the next WG meeting in two about two weeks +19:02 lol, I wasn't told there would be homework ! +19:03 @Eijebong cheap excuse, write 4 pages on a proposal for assert_cli 1.0 for the next meeting +19:03 1. Do we just open issues for the initial batch of jobs? +19:03 2. Does one person does it so we don't accidentally have two issues for one task? +19:04 2 sounds a better idea +19:04 Meh *opens up latex* title page, thanks, summary, blank page at the end for people to take notes, am done ! +19:04 let's each write what issue we want to open here and then open it? +19:04 there, data race solved +19:04 takes longer than 1 person opening all the issues :P +19:05 okay, _fine_ i'll open a bunch of issues :P +19:06 lol @killercup you got homework! :smile: +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 +19:06 speaking of opening things on github: people alright if I PR the stuff we discussed here as a meeting note for today? +19:06 e.g. C-c the IRC log into a file ✨ +19:06 smart Katharina :smile: +19:06 @spacekookie you can edit issues later ;) +19:07 @yoshuawuyts I think there is already an open issue for the meeting notes. +19:07 @killercup Alright ;) +19:07 Also yea @yoshuawuyts Maybe just add the meeting notes to issue #1 +19:07 @yoshuawuyts feel free and add "fixes #1" +19:07 :+1: +19:07 cool! +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!) +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 +19:08 gaps in the ecosystem where a new crate could come in) and each of those could be broken down as well. +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 +19:09 yah i agree with Kevin +19:09 @kbknapp yes! +19:11 And like @killercup already said, *we* don't neccessarily 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 +19:11 necessarily* +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) +19:12 sounds cool +19:12 :+1: +19:12 :+1: +19:13 @killercup I will have to leave. Thank you very much for organizing this! +19:13 @sharkdp thank you for joining us! +19:13 Bye @sharkdp thanks! +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 +19:14 Thanks for herding us @killercup ! +19:14 thanks y'all!