Hey @asmecher , thanks for the question.
Yes indeed, the rationale is to reduce the total amount of tools needed to compile a successful build. Getting the dependency on git esp. with its submodules out of the way and moving the handling of repositories or tarred releases of dependencies for development and production strictly into the preferred package manager of the language ecosystem of choice, here PHP.
This would make it easier to follow developments in other places of the community, given they also treat composer the same way, such as Laravel, Artisan, Eloquent or Flysystem, and to piggy bag from them.
Turning the suite of PKP and OJS artifacts into Composer packages might also bring other network effects with regards to adopting more recent PHP development patterns available since introduction of the v8 series, like type systems or more functional idioms around immutability and statelessness of methods.
If the Composer can be asked to also deal with orchestrating the whole suite of tools involved in development and building the application, e.g. using scripts, the better.
Composer can deploy from git, but because the Composer config is in the lib/pkp submodule already, any attempt to use it to deploy the submodules would require moving it into the application repos, which would be a significant amount of config duplication.
Maybe we can find a way that models nicely around common development and build usage patterns? It seems “falling back” to the convention of a package manager instead of raw git about how to define and reference dependencies seems like a possible risk to take?
What about invoking Composer commands in submodules through scripts in composer.json of the root repository in the meantime?
We have been discussing the possibility of moving to a monorepo approach to avoid some of the headaches involved in developing with submodules – primarily frequent merge conflicts with the lib/pkp submodule. But if we choose that path it’ll be a while before it can be realized.
What is blocking you from copying a working checkout into a single repository or why would that still take a while, if I may ask? You could try moving such an example over into a new repo, work from there for a while and evaluate your findings of the experiment against the original hypotheses to see, if they worked out?
Ideally I’m considering a flat tree structure like the following in dream code for defining a single OJS instance:
composer.json
defining:
├── ojs tag
├── lib tag
├── theme tag
└── plugin{s,…} tag
Turning OJS and the library into peer dependencies seems to avoid some of the nuisances you mention. Thus the dependencies of a complete instance will be, are and can be described in a single file, turning that into the single source of truth about the Software builds used for an instance.
Which in return nicely closes the circle to the original subject of the thread, allowing to computationally determine the SBOM: Unmarshalling semi-semantic JSON for attestation still brings more metadata than a raw .git and .gitmodules environment and better addressing of that metadata in its respective Composer namespace. The framework also provides us with guiding principles in shape of sufficient conditions to make working with it possible.
Consolidating on a single build tool orchestrating the other(s) may ultimately help achieve reproducibility with less layers of abstraction involved.
How do you think about this?