[RFC] Hollowing out LOX

[helgee]

Sorry, for the silly pun in the title 😬 Correct title: "Splitting lox_core"

I am considering to split lox_core into separate crates, e.g. lox-time, lox-ephem, lox-comms, etc., since it is becoming quite unwieldy already. My expectation is that this will lead to cleaner public APIs, looser coupling, and the ability for end users to only use what they need and add fewer transistive dependencies. The lox-space crate would still depend on all lox-* crates and provide a prelude and a way to use the whole framework by adding only a single dependency.

Thoughts?

P.S.: I would like to consistently use kebap-case for the top level cargo packages. Objections? Opinions?

[AngusGMorrison]

I fully agree – large crates can be a pain to work with, especially as compilation time starts to get out of hand.

For lox-space, let's consider putting each of the components (or each logical grouping of components) behind features, allowing the users to opt in or out of them based on their requirements while maintaining the single-dependency approach.

I have no objections to kebab-casing. The Rust community hasn't settled on a convention for crate names, and it's best not to overthink these things.

That said, would you mind holding off on this until after the fundamental arg changes are finished (nearly there)? Otherwise the merge conflicts will be hell.

[helgee]

For lox-space, let's consider putting each of the components (or each logical grouping of components) behind features, allowing the users to opt in or out of them based on their requirements while maintaining the single-dependency approach.

That's the idea 👍

[matzipan]

I don't have any objections to any case.

If we want to be pedantic about it RFC 430 does say snake case

[AngusGMorrison]

I believe this is now done, so I'm closing this issue.