Initial sub-crates

[vitiral]

The following intial crates are targeted towards the following weeks:

• [ ]: ergo_prelude: "generally needed stuff" -- lazy_static, maplit, failure, itertools, std_prelude, ordermap, etc.
• [ ]: ergo_sys: deal with operating system details. Examples include time (chrono), signal handling chan-signal, (maybe) system libraries (libc) and randomness (rand).
• [x]: ergo_fs for files+directories. Some crates could be path_abs, walkdir, tar repo
• [ ]: ergo_config deserialization and config files+env-vars: toml, serde_json, serde_yaml, configure, shell variables (shellexpand), etc

Something that the ecosystem isn't quite ready for but is probably close

• ergo_term: terminal input/output styling: tabwriter, pretty_tables, termstyle, etc
• ergo_test: test framework conglomeration, not particular to any particular application

I'm considering not exporting std_prelude, and instead each crate exports the relevant traits/types in it's own prelude. I think this is the right approach.

[vitiral]

other sub-crates:

• ergo_sync: provides an ultra-simple API for using Sync types, i.e. running threads. Included:
  • rayon with some additional macros:
    • join! can be used to join an arbitrary number of closures which may run in parallel
  • chan: this is pretty much directly exported as the API is extremely ergonomic
• ergo_async: the ecosystem is definitely not yet ready for this, but eventually this will be some kind of async layer
• ergo_client: libraries for acting as a client. Will primarily include reqwest, h2, and probably some kind of json-rpc types

@killercup thoughts on these?

[BurntSushi]

Quick thoughts:

1. You might reconsider chan-signal. It doesn't work on Windows, and while this project hasn't said anything about platform support (?), it is probably a good idea to keep Windows as a first class citizen.
2. chan is hopefully in line to be deprecated soon in favor of crossbeam-channel: https://docs.rs/crossbeam-channel/0.1.2/crossbeam_channel/

[vitiral]

Thanks for the feedback! Ya I was actually thinking these exact thoughts. I'm almost done evaluating crossbeam-channel and was going to include ctrlc as the included library, with examples. (and just recommend some crates that could be used for posix only systems).

[vitiral]

See the below issues for ergo_sync. I have a feeling ergo_sync will be beta for quite a while:

• scoped-threads + macros: crossbeam + scoped threads ergo_sync#3
• crossbeam-channel + macros: Use crossbeam-channel for the channels ergo_sync#4

[richard-uk1]

Can I register my interest for helping with ergo_term.

I was planning to attempt a platform abstraction library for terminals, but working as part of a team would increase the chance of my work being useful/getting finished.

My plan for the term library was as follows:

I would design it first as an API with the assumption that all capabilities are preset (color, cursor relocation, etc), and then panic on platforms/systems where they are not available, along with an API to get available terminal capabilities.

Then, we would want to implement this for a lot of different types of systems. Embedded systems with a serial cabel right through to ansi terminal in windows 10, but including support for old terminals on windows.

Prior art:

• term - from rustc: There's a known memory leak in the windows implementation.
• ansi_term: great for ansi terms
• anything in the 'terminal' category on crates.io
• anything with keyword 'terminal' on crates.io

I'm not sure if this library aims to be higher-level, or not, but either way I have some knowledge of terminals on windows and posix, so hopefully I would be useful.

[vitiral]

@derekdreery absolutely! I should mention that this is (in my opinion) one of the more challenging conglomeration crates -- but I think it is absolutely needed as well.

I opened #9 for further discussion. Thanks for your interest!