Integrate with the ergo ecosystem

[vitiral]

Hey @killercup, you've probably been waiting for this feature request 😄

I am nearing completion of the initial release of ergo. There is a LOT of overlap between these two crates but there is also several areas that there is not overlap.

My suggestion is to have a minimal feature set which only

• exports the main! macro
• exports log and envlog crates and types
• exports structopt macro and types
• exports failure macros and types

This would allow quicli to fit cleanly within the ergo crate ecosystem, as I have no desire for ergo to perform these operations. Theoretically I could create an ergo-cli crate which is pretty much a fork of quicli with these features -- but I don't want to do that!

Another advantage of this is that it could be part of the "story" of developing an application:

• when you start out, use just quicli
• when you need a larger stdlib, set features=minimal and import ergo
• keep rusting!

[vitiral]

I think this kind of "story" can also help with #19 to tell the purpose of quicli. It is an entry point for beginners and a helper when your knowledge expands.

This will help reduce the amount of "should this crate be part of quicli" discussions -- most of those could be redirected to the relevant ergo subcrate.

[killercup]

I'd love to have quicli become a base crate for ergo. While I was initially skeptical of adding feature flags, I think I'm okay with adding them for this purpose. Please note that cargo features are additive: If crate A and B depend on C, and A requires feature X while B wants feature Y, C gets compiled with both X and Y. This, I can't add a 'minimal' feature, as it takes functionality away. I can however add features that are enabled by default ('slowly', 'quickly' and 'full-throttle' for example) and ergo can set 'no-default-features'. Garrett Berg <[email protected]> schrieb am Mo. 5. Feb. 2018 um 02:29:

…

I think this kind of "story" can also help with #19 <#19> to tell the purpose of quicli. It is an entry point for beginners and a helper when your knowledge expands. This will help reduce the amount of "should this crate be part of quicli" discussions -- most of those could be redirected to the relevant ergo subcrate. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#43 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABOX2G23CaMUfzQpnZNQ-jXTyQ9EKo4ks5tRlmQgaJpZM4R4zih> .

[vitiral]

Awesome! 🎉

How about just a full-throttle feature as the only default feature (for now), and ergo will work with just no-default-features.

I would like to unify the docs as well, to tell the full story. Basically the story is this:

Getting Started Guide

This is the kind of person who is not familiar with rust, or at least not familiar with the full ecosystem and how to build an application.

They are directed to use a cargo like this:

[dependencies]
quicli = "0.X.X"
serde = "0.X.X"
# ... other `derive` dependencies

The "cookbook" guide then looks very similar to what it does today (but we will keep improving them 😄)

Next Level: full ecosystem

At the next level, they are instructed to use a Cargo.toml like this:

[dependencies]
ergo = "0.X.X"
serde = "0.X.X"
# ... other `derive` dependencies

[dependencies.quicli]
default-features = false
version = "0.X.X"

We then basically replicate the rust cookbook, as well as additional examples, using this as the ecosystem. I would like one of the primary goals of ergo to be that it should be able to do almost anything from within the rust cookbook with zero additional dependencies.

Usecase

I think I see clearly now how these two crates interact:

• quicli is for reducing boilerplate to quickly setup a CLI application. It is intended only for --bin crates.
• ergo is an ecosystem of crates built for high level libraries, including --bin crates. It is also split into subcrates (i.e. ergo_fs) for some lower level libraries.

Let me include a use case, which is the CLI application I am rewriting.

artifact will be (eventually) split into 3 crates. Their dependencies (roughtly) would look like this:

                 ---- artifact-data
                /       - ergo
               /
artifact-app -------- artifact-web
 - quicli               - ergo
 - ergo                 - yew
                        - gotham

As you can see, the two "high level libraries" can feel free to depend on ergo. In order for this to be ergonomic, ergo must not include libraries like StructOpt and envlogger, which should only exist in --bin crates.

Conclusion / Vision

I think these two libraries can interact very nicely, and I think our first goal can/should be to rewrite the rust Cookbook using these libraries.

I'm currently reviewing the API guidelines and plan on contacting the libz blitz team and see if we can share knoweldge/expertise. The ideal case would be that the cookbook we work on writing will be the rust cookbook once ergo and quicli are stabilized. I would like to see if bringing the libz blitz team onboard would allow those goals to align.

Before that though I am going to actually use ergo and quicli as they exists today to rewrite artifact and port some of the cookbook. I will be making frequent changes/PRs for any bugs I find.

Does that all sound like a reasonable strategy?