ergo ecosystem approach

[vitiral]

This issue is to outline one possible approach to improving the discoverability, interopability and ergonomics of the rust ecosystem, which is the ergo crate ecosystem

Goals From the README

The Ergo Ecosystem is an effort to unify the rust ecosystem at critical sections. It is currently focused on improving Command Line Interface (CLI) ergonomics. To accomplish this it will create multiple targeted conglomeration crates. These crates do much more than simply exporting the API of their sub-crates. They implement wrapper types to unify them, as well as have tested documentation to ensure they interopate together reliably.

Ergo's current goal is to be a full featured CLI SDK, built from composable and distinct sub components. You should be able to depend on the ergo library itself or each of its sub components individually.

Ergo aims to provide the following benefits:

• A standardized API for disparate types/approaches, allowing library authors to develop simple libraries of high quality, which can then be combined into an ecosystem with a unified API and excellent ergonomics.
• A starting point for CLI and application developers for documentation and How To guides. We hope to release an Ergo Cookbook once the libraries are more stable.
• Encourage interopability, quality, and ergonomic errors among the major CLI crates in the rust ecosystem and act as a driver towards higher quality and uniformity.

Further Goals

The fundamental goal of ergo is to make working in rust with ergo feel like a completely different language. The goal is essentially that there are three possible "experiences" with rust:

1. Developing using rust with no_std -- very clean compared to general embedded development, but a lot more verbose than "normal". Typically requires the use of fairly advanced features. The embedded-WG is working on this area.
2. Developing using rust with std and crates: way less verbose, but you still have to have a good idea of the ecosystem to be productive since std is just not big enough for the majority of use cases.
3. Developing using rust with ergo (or similar "crate ecosystem"): most things you want that are not application specific can be accessed/looked up quickly. It should feel a little like working with python: the stdlib is slightly overwhelming, but at least you know where to look for most "basic" operations you want to perform!

I think the ecosystem-WG should focus on making both item 2 and 3 better, as they actually feed into each other. By creating "crate ecosystems" we will uncover interop and API gaps which can be fixed regardless of there being a crate like ergo.

[Enet4]

Ok, took me a while to grasp the ergo concept. It's like we enter python-land in the sense that a single dependency contains nearly everything we need for a certain ecosystem.

I have two questions for the time being: since there appears to be a major focus on CLI applications at the moment, yet currently there's only a recommendation of the use of quicli, will this one be inside an ergo sub-crate eventually? Also, how opinionated will the sub-crate be? If I just want to use clap, will I have to add it separately?

[vitiral]

• quicli will be eventually be integrated with ergo (Integrate with the ergo ecosystem killercup/quicli#43). Basically ergo is the "library level" whereas quicli is only for the "cli frontend". The idea is that you use just quicli to get started and then incorporate ergo and then go from there.
• ergo doesn't include clap (that is quicli's layer) so you would have to add it separately. In general it will be pretty opinionated on which crates are included (i.e. not providing alternatives directly), although that is just my own personal opinion and I am certainly open to feedback. Do note that it intends to stay in alpha/beta for quite some time, so subcrates will be added/removed quite quickly for the near-term future as we figure things out.