Split components into separate repositories
For now, everything in the Soong ecosystem is in the same repository - with APIs still changing regularly, it's much simpler than trying to keep dependencies in sync across repos. Once the APIs are fairly stable, though, and definitely before the 1.0.0 release, we'll want to split things up. The proposed structure is:
- soong/soong (this project) - interfaces, at least (see below).
- soong/console - Symfony console commands.
- soong/dbal - Components integrating with DBAL.
- soong/csv - Components integrating with league/csv.
Those last three are pretty obvious split points, but we have some less clear ones:
- Should
OptionsResolverComponentand the base classes extending it - i.e., the integration with Symfony OptionsResolver - go in thesoongrepo, go into their own repo, or go into something like asoong/basicsrepo? - Should our basic
PropertyandRecordclasses (and their factories) go into thesoongrepo, go into their own repo, or go into something like asoong/basicsrepo? - Should our basic
Task,EtlTask, andTaskPipelineclasses go into thesoongrepo, go into their own repo, or go into something like asoong/basicsrepo? - Should the most commonly used
Transformerclasses likeCopyandKeyMapLookupgo into thesoongrepo, go into their own repo, or go into something like asoong/basicsrepo? - Should the most commonly used
Filterclasses likeSelectgo into thesoongrepo, go into their own repo, or go into something like asoong/basicsrepo? - Should basic components useful for testing and debugging, like
ArrayExtractorand theVarDumploader, go into thesoongrepo, go into their own repo, or go into something like asoong/basicsrepo?
At the moment, my inclination is to move the latter bunch (except the testing/debugging stuff, which is used by test base classes) to a soong/basics (or somesuch name) repo and we can then see if there's any motivation to split things further.