Improve ecosystem discoverability

[killercup]

In the first meeting, we discussed ecosystem discoverability.

The goal is to make it easier for people to get the right tools they need to smoothly write CLI apps in Rust.

[killercup]

One idea, championed by @vitiral is to provide an "extended std lib" that collects a bunch of useful crates and exposes them with a unified API surface.

Implementation is currently under way at https://github.com/rust-crates/ergo

[killercup]

Another idea is to use cargo templates (Pre-RFC) to help new users get started by providing them a project setup that already contains a bunch of tooling.

[kbknapp]

My primary concern with crates that only expose other crates is they are a big burden to maintain. There have been several other attempts and they all fall short (see things like stdx), unless they're officially maintained. The also cause downstream crates to lag behind unless the "combination crate" authors quickly stay on top of the crates they're exposing.

I'm even victim of it too with things like cargo-extras. I'd prefer some officially maintained "lists" of where to go for what functionality. Granted, those need to be maintained too...so it's not much better 😜

[XAMPPRocky]

I think with the deprecation of extern crate and only requiring dependencies to be defined in the Cargo.toml would alleviate a lot of the issues of starting from scratch and can be used with templates.

[vitiral]

@kbknapp

My primary concern with crates that only expose other crates is they are a big burden to maintain. There have been several other attempts and they all fall short (see things like stdx), unless they're officially maintained.

ergo has some different goals than stdx. The big ones are:

• It serves a specific use case: CLI ergonomics
• It aims to unify the API of it's sub crates through lightweight wrapper types
• It aims to be owned by the community, whereas stdx was owned by just brson and when he stopped rusting it was defacto unmaintained.

Also, stdx is only one attempt and I would say that it was not a complete failure. For me, it helped me discover more parts of the rust ecosystem. I wouldn't discount the future of rust SDK's just because of stdx.

On the other hand creating a full fledged CLI SDK is a major commitment and I think will require a lot of experimentation to get right. There is going to be a lot of churn on the API as the subcrates are chosen and become 1.0 -- so whether it should be a major focus of this group is a serious question. I would much appreciate the group's blessing for a "long term plan" though! Also I think that by attempting the experiment it will provide us a good lense of "what API do we want the CLI ecosystem to have?" -- which would be useful on its own IMO.

Note that ergo is split into sub-crates, each with maybe 5-6 wrapped crates max. Maybe we could attack only some of those? ergo_fs, ergo_sync and ergo_config address pretty clear goals of rust CLI ergonomics IMO, and thinking about what their unified API should be is a great way to get an idea of what we even want.

[Dylan-DPC-zz]

On the other hand creating a full fledged CLI SDK is a major commitment and I think will require a lot of experimentation to get right

I feel without attempting this it will be difficult to solve majority of shortcomings the current CLIs are facing.

[luser]

I think rather than trying to write a mega-crate that solves everyone's problems it would be better to focus on having a set of crates that work well together by obeying common conventions, etc. I'm happy to be proven wrong, though! Work put into such a crate is unlikely to be entirely wasted anyway since it will inevitably use a number of other crates so improvements to them will benefit everyone.

[epage]

One idea that came out of RustBeltRust last year was to have crates link to related crates. I then went and did this for assert_cli, linking to dirdiff, tempfile, and duct.

Has there been any talk of an algorithmic version of this for crates.io where it correlates common direct dependencies (people who depend on clap also tend to depend on...)?

The human approach is still nice for up and coming crates that an algorithm might not pick up on.

[softprops]

Related to the cargo template idea, I created a similar tool a while back http://github.com/softprops/porteurbars based on some lessons learned from working on https://github.com/foundweekends/giter8 in the past. I this this solves a productivity problem more than it does discoveribility problem based on experience.