Monorepos yay/nay?
Closed this issue · 5 comments
I am a big fan of monorepos, since versioning, and features can be built/tested/reviewed and documented well (github comments etc.) for future contributors.
What can get a bit out of hand usually are CI workflows, but I have also managed those across large projects in previous years, so not an issue imo.
We could have at minimum the program and client here, UI could be separate? python client could also live here maybe? What else?
I typically prefer monorepos.
I'd say 'Nay'. I'm not a fan, but I'm not overly tied to avoiding one.
I think it creates issues in security and versioning, and increases the workload.
For instance, granting someone write access to the current mango-explorer repo has some security concerns. Granting someone write access to a monorepo of all code has a lot more security concerns. That can only slow down granting access to parts of the code. Individual repos have more granular security.
Right now the release process for mango-explorer packages all the code into a zip file, tags the code with the version, builds the docker container and the Pypi package. The same approach in a monorepo will result in an awful lot of irrelevant code getting tagged with mango-explorer version tags.
Maybe I'm just missing how independently releasing subsystems works in a monorepo? Are tags just not used?
A monorepo can increase visibility, but that's a two-edged sword. It can be nice to have visibility of issues around all areas of the code, but it also means you have to read every issue that comes in to see if it applies to you - an issue that would be restricted to mango-explorer now gets sent to everyone, as do issues that would be restricted to mango-client-v3 or mango-v3.
It's not that the above problems aren't solvable - I'm happy to change the release process, and I'll cope with the inundation of emails. I'm just not sure I see the benefits.
For instance, granting someone write access to the current mango-explorer repo has some security concerns. Granting someone write access to a monorepo of all code has a lot more security concerns. That can only slow down granting access to parts of the code. Individual repos have more granular security.
I think non organisation members should submit patches with PRs from their own forks
Right now the release process for mango-explorer packages all the code into a zip file, tags the code with the version, builds the docker container and the Pypi package. The same approach in a monorepo will result in an awful lot of irrelevant code getting tagged with mango-explorer version tags.
Maybe I'm just missing how independently releasing subsystems works in a monorepo? Are tags just not used?
yeah tags usually have prefixes, e.g. program-v1, ts-client-v1, py-client-v1, but ideally we should be able to do major releases in sync.
A monorepo can increase visibility, but that's a two-edged sword. It can be nice to have visibility of issues around all areas of the code, but it also means you have to read every issue that comes in to see if it applies to you - an issue that would be restricted to mango-explorer now gets sent to everyone, as do issues that would be restricted to mango-client-v3 or mango-v3.
For me the giant benefit of seeing a feature having changes across program and all clients is this - easier to review and double check if someone missed something, newer contributors willing to contribute across entire stack is easier since they can refer to very good end to end examples, Update: this all makes it easy for existing contributors to contribute to other sub projects in the repository by passively learning from large PRs
It's not that the above problems aren't solvable - I'm happy to change the release process, and I'll cope with the inundation of emails. I'm just not sure I see the benefits.
Usually you can have tags on issues, but yeah the tags would be kind of post issue creation, btw the issue activity on all mango repositories is very low ;)
@OpinionatedGeek I thought a bit more, and what we could have is a the basic minimal python client in this repo, and the whole full blown mango-explorer project in a separate repository, maybe that would be a better fit...
I think non organisation members should submit patches with PRs from their own forks
I agree, but a monorepo would move it from 'should' to 'must'. And that's fine, as long as it's an explicit choice.
For me the giant benefit of seeing a feature having changes across program and all clients is this - easier to review and double check if someone missed something, newer contributors willing to contribute across entire stack is easier since they can refer to very good end to end examples, Update: this all makes it easy for existing contributors to contribute to other sub projects in the repository by passively learning from large PRs
I'm not saying I don't see the benefit, I'm just saying it doesn't seem 'giant' to me. (I
can see benefits of having one PR for a change across multiple clients but I can see drawbacks to that too.) What fundamental problem is a monorepo trying to solve? Is it really just that navigating inside a repo is better/easier than navigating between repos? That having one repo to send programmers to is better/easier than a list?
Usually you can have tags on issues, but yeah the tags would be kind of post issue creation, btw the issue activity on all mango repositories is very low ;)
The issue activity on a monorepo will never be lower than the issue activity on one of its constituent repos...
I thought a bit more, and what we could have is a the basic minimal python client in this repo, and the whole full blown mango-explorer project in a separate repository, maybe that would be a better fit...
That would remove a lot of the end to end examples you mentioned (where a CLI command runs Python to call Solana to run Mango Rust), and would probably mean the end of development on mango-explorer (which is fine, if that's what folks think is best).
As I said, I'm not outright against the idea of a monorepo, and if that's what folks prefer go for it. I guess I'm just not the one experiencing the problems it's going to solve.