#AskFedi: I have a Rust question. My usual approach to developing a collection of modular (but related) libraries in JS is:
1. Start with one monolithic package, in which everything is developed initially.
2. But opportunistically minimize assumptions between parts of the package, so that internally it is already mostly modular.
3. Spend some time figuring out reasonable APIs for the remaining, more-difficult-to-modularize cases.
4. Eventually split out all the internal parts into separate libraries/packages and publish them independently, so that users can select only the parts that they need, and easily combine it with third-party libraries.
What would a good workflow for this look like in Rust, especially in terms of internal crate layout (in step 1) so that it's easy to split out into separate crates later, but also in terms of tools to use?
I do not use monorepos, each crate will have its own repository in the end. Also, contributors must be able to use standard Cargo commands to manage the different crates, so no 'wrapper scripts' or third-party tools (unless they can be made to run from within Cargo).
@joepie91 The initial crate layout basically has what would later be separate packages as submodules, and there are some attempts to minimize circular dependencies between them. (unfortunately, in the Topola case, the usage of `enum-dispatch` turned out to make that really difficult, so one has to be somewhat attentive to how one chooses utility procedural macros)
@joepie91 Such granularity in packaging is something I do not recognize from Rust. Packaging as a monolith is more common.
If you have modules for interoperability with other, optional, packages you could solve this with Cargo features?
@joepie91 I don't know what tools to use (because so far, I've only done such stuff manually).
Not using a monorepo seems to make this more difficult (but one could start with a monorepo and get rid of it / replace it with individual repos when 4. is done). For that transformation, https://github.com/newren/git-filter-repo/ is really useful.
It's what I've used for similar splits in the past, e.g. extracting https://codeberg.org/topola/contracts-try from https://codeberg.org/topola/topola.
For another submodule, (2.) https://codeberg.org/topola/topola/commit/0fe23c9c71e4af5d455d79bc1b586951bd9a23cc