Should #Logarion's repository be split into multiple sub-repositories?
@orbifx trying to figure out the answer to this question for one of my projects. Pros for sub-repos: separate issue trackers & easier sharing of the code for multiple dependencies. Cons: extra complexity & dev confusion. Maybe start with a monorepo and split out a sub-repo when you notice you're frequently updating the same code from multiple dependent projects?
@latersauctro I'm more concerned about noise in the history from independent parts of code now living in the same repository only because they are related in the ecosystem. The have been a mono repo which can also be installed by #OCaml's package manager (#opam) but it pulls the dependencies for all modules, servers and front-ends.
@orbifx It's an open science project -- diagrams for communicating discoveries in biological research: https://github.com/wikipathways/wikipathways-upgrade-2017 The extensions directory only has sub-repos, but many of them have a single dependent: the parent project.
@orbifx With or without sub-repos, what do you think about installation/deployment? Should the git repo(s) be for development and opam (in your case) be for a production installation? How does a new dev get started initially -- maybe with a bash script that handles installation for the parent repo, including calling an install command for each sub-repo?
@latersauctro binaries for deployment. This trend of installing gigs of tools and dev libraries is not on. @Git only for modifications, #opam for dev dependencies (not production unless it's a library), and binaries for production.
Readme's for bootstrapping devs. Best if they know what they are getting.