Roadmap

[vitiral]

This post was originally posted by @killercup here but it seems that only members of the ergo team can use that link

Hey, thanks for inviting me to this team. Since clicking the team link brought me to this new team discussion feature of Github, I'm gonna use it!

Roadmap

What is your roadmap for the ergo crates? In killercup/quicli#19 (comment) you wrote a bit about which "combining forces" crates you wanted to see:

• cli_system: deal with operating system details. Examples include time (chrono), signal handling ctrlc, system libraries (libc), shell variables (shellexpand) and randomness (rand).
• files+directories. Some crates could be path_abs, walkdir, tar
• deserialization and config files: toml, serde_json, serde_yaml, etc
• terminal input/output styling: tabwriter, pretty_tables, termstyle, etc
• There also need to be "generally needed stuff" -- lazy_static, maplit, failure.

ergo_fs is the first step here. Do you want to polish this, or begin work on another crate right away?

I'll personally be quite busy with dayjobs.iter().collect::<Money>() for the next few weeks; the time I have, though, I'll try to invest on pushing quicli towards a usable and semi-feature complete state.

Infrastructure

Do you want to make template for setting up projects in the same way? With travis/appveyor/bors, licenses, github issue/pr templates, contributing file/CoC?

I'm working on the docs setup for quicli right now. Feel free to copy that :)

[vitiral]

My response was:

@killercup Thanks for the creating this issue!

Initial Plan

I think my first plan of attack is to "just build the crates" -- I posted those issues to the README with checkboxes, and I plan on attacking one after the other.

It is a good point that I should simultaniously get the build automation set up, since that is for the most part "just" a couple of templates. I've already got a pretty decent template for travis+appveyor. I'll try and figure out bors, PR-templates and add the COC (it's just going to be a link to rust's CoC) as well before I make any new crates.

Rough Iniital Roadmap

This is my the rough roadmap I have in my head:

• next month or two: flush out the "easy" conglomeration crates, build up a decent API with excellent docs and some amount of fuzz testing where it makes sense.
• During that + a few months: work on unifying the versions of dependencies in the ecosystem. I would like the dependencies in the ergo ecosystem to accept broader sets of versions (i.e. rand = ">= 0.2.5 < 0.4" instead of just rand = "0.4"). I would like to setup some kind of automated test that tests a crate with both its lowest AND highest versions in travis+appveyor and get those tests added to the CI of crates we depend on, then leveraging it to broaden allowed dependencies across the ergo ecosystem.
• After that, write the Ergo Cookbook which is a recipe book for applications built on ergo, and will also serve as our primary test suite (after the library docs).

Over the next year I plan on continually breaking ergo libraries, always staying at the cutting edge, refactoring APIs where necessary, cleaning up dependencies, etc. The long term vision I have for the ergo ecosystem is:

• 2018 unstable development: experimentation, API cleanup, dependency widening. There will be frequent bumps to semvers, and dependencies will be intentionall not nailed down, meaning if you depend on ergo will you will always be at the cutting edge and should be quick to open bug reports 😄
• 2019 stabilization effort: the ecosystem should begin to clamp down on dependencies, prune libraries that are not 1.0 and hide them behind an unstable feature gate, etc. During this time a stabilization policy should be created. Also, ergo should expand into other domains far outside of cli applications, such as frontend/backend web, data analytics, etc. This is also when we would release the ergo crate itself, which is the "full batteries" of the rust ecosystem.
• 2020 1.0: The core ergo libraries have hit 1.0 and are considered "stable" and have some form of stability guarantees. The Ergo Cookbook can guide you on creating a wide variety of applications quickly and easily, and is a goto point for beginners learning the rust ecosystem.

I am extremely open to feedback on this vision. This is mostly my own thoughts of what ergo should become.

[epage]

cli_system: deal with operating system details. Examples include time (chrono), signal handling ctrlc, system libraries (libc), shell variables (shellexpand) and randomness (rand).

• chrono doesn't seem cli-specific
• rand doesn't seem cli-specific

I imagine some other crates that should be involved or recommended here are app_dirs and/or config

[epage]

I think it'd be worth reaching out the to easy_strings author to see if he is willing to move it under this umbrella project.

[vitiral]

@epage

• whoa, app_dirs is super cool!
• I only skimmed the docs for config but I feel a bit overwhelmed... what exactly does it do and how does it do it? It seems like it does live loading of config files, but the docs are hard for me to follow.
• rand/chrono: the point of ergo isn't just for CLI's, although that is the primary first use case. And I disagree, randomness and handling time are often needed in CLIs. For instance: creating a random file name or logging how long something tool. Also, I think chrono should be replaced with the time crate, since it is a bit simpler and more widely used.

Easy Strings

I think it'd be worth reaching out the to easy_strings author to see if he is willing to move it under this umbrella project.

In general I don't think that crates should move under the rust-crates project unless the maintainer is going on haitus or something. Even then I would be pretty hesitant until the rust-crates group is larger and want to take on the maintenence burden.

As far as the crate itself goes I'm not sure I'm completely sold right now. What are the major benefits? It seems like they are:

• Some improvements to ergonomics, especially concatenation but also splitting/trimming return owned values
• Possible memory improvements at the cost of performance. How much cost is that? It seems like there is a lot of hashing going on under the hood as well as a global hashtable of existing easy strings?
• How much of the API improvements could be handled with a StringEasy trait or something that is implemented for &str and String? How much more cost would these improvements be?

The major cost as I see it is in just adding another string type. Plenty of people are already confused about &str vs String vs Cow<&str> 😄

[epage]

I only skimmed the docs for config but I feel a bit overwhelmed... what exactly does it do and how does it do it? It seems like it does live loading of config files, but the docs are hard for me to follow.

I've not yet noticed anything about live reloading. The neat thing about config is that it helps you manage multiple sources of configuration (environment variables, per-user config, global config). I've not yet seen how it helps with managing command line arguments that impact configuration.

[epage]

In general I don't think that crates should move under the rust-crates project unless the maintainer is going on haitus or something. Even then I would be pretty hesitant until the rust-crates group is larger and want to take on the maintenence burden.

Personally, I think there should be a dedicated ergo org for all things ergo to live under. I keep forgetting that isn't the case which is why I recommended talking to the other about joining forces, including moving all the code into one org.

As far as the crate itself goes I'm not sure I'm completely sold right now. What are the major benefits? It seems like they are:

ergo_fs expands path types from 2 to 8.

I was working under the assumption of ergos goal is to make programming in Rust to be higher level at the possible sacrifice of performance. In this case, something like easy strings would make it so the target user only has to worry about one string type. The docs would then give guidance on interop.

[vitiral]

In the case where the library author wants this, maybe. But most people write libraries because they *enjoy it, *and they probably want to continue being the primary owner. Personally, that vision isn't what I had in mind. But again, I want ergo to be much more than me, so I'm open to what the community thinks. (also ergo is *really *young, so I think doing this kind of thing now would be premature) I get what you're saying now for EZString. I'll have to take another look at it.

[epage]

I was working under the assumption of ergos goal is to make programming in Rust to be higher level at the possible sacrifice of performance.

Personally, that vision isn't what I had in mind.

I must have misunderstood our conversation from reddit:

Thanks for the feedback. The goal is indeed to be "easier than python" -- we should put that somewhere in the design goals!

[epage]

In the case where the library author wants this, maybe. But most people write libraries because they *enjoy it, *and they probably want to continue being the primary owner.

Consolidating under a shared org is not meant to take people's baby from them but to

• Give them support where needed. For example, with my crate-ci org I'm creating, my vision is that someone can just go through and update all cargo subcommands to new versions of cargo while the author focuses on what they want
• Help in transition if an owner needs to step away

This is presupposing that the person is maintaining the crate because it is of interest to them and not because it was expedient for them (needed dependency, onetime idea experiment, etc). In this case, they probably would appreciate help in adding features, support, etc.

See also killercup's post

So the key thing is we should at least ask people rather than presuppose.