Hacker News Reader

Hacker News

Comment by amelius | Hacker News Reader

Full thread

amelius

What tools are people using to manage multiple repos? A search reveals many, but what is the latest and greatest?

View on HN

NuGET, Maven, whatever is the package manager for the language in question.

The outcome of multiple repos should be modular libraries.

> The outcome of multiple repos should be modular libraries.

Yes; also they should all be treated as separate, independent products. Where multi-repos go wrong is when a whole product spans multiple repos, and a feature of the product depends on features being added or altered in multiple projects.

Ideally, the split should be so that nobody has to work across multiple repos to finish a feature.

The github / NPM ecosystem is IMO a good way to look at it; libraries that are all independent of one another who have a (usually pretty good) adherence to semver.

> Ideally, the split should be so that nobody has to work across multiple repos to finish a feature.

That does not sound realistic. Often I have to add a new function, and I think: where (in what library) does this function belong, and very often it's not the main library I'm working in at that moment.

Adding a new function anywhere other than the leaf project where it's used is premature. Organize around user-facing functionality. Pull out common libraries as and when you have something common enough to factor out (and, crucially, test independently), not before.

So the answer to needing to open multiple PRs is to open multiple PRs.

The answer is to adapt your working patterns so that you never have multiple PRs on the critical path. Long-term codebase quality may require multiple PRs, but delivering user-facing functionality doesn't.

And what if I wanted to add a method to a class? Or a method and a data member?

You get the library owner team to do it and bind to the new released version.

Microservices without network headaches.

Usually libraries are owned by separate teams.

Unless you're a library vendor, the outcome of multiple repos is most likely a single final application. Or a few applications.

That is not a reason not to write modular code.

Modular code works just fine in subdirectories.

Not when it gets compiled from scratch all the time, or is open to spaghetti code modifications.

Modular code in subdirectories is what gave microservices an excuse against the "monolith".

It can work either way. There are pros can cons to both ways, code organization needs to be done correctly either way. Nothing about either ensures your code is a good modular structure vs a haphazard mess. In most cases code in fact has a modular structure behind it that is followed - but the structure is not always good (something that is easy to see in hindsight, but the wrong rules were put in place early and now it is hard to change)

Mono repo makes violation of modular rules easier, just link it in - in a complex project odds are nobody will notice. However this doesn't mean monorepo is bad, it just needs that you need to be careful to ensure the rules are written down.

Multi-repo makes violation of those same rules harder - you have to make a bunch of changes to ensure that the bad dependency is in the environment. This hints at the downside of multi-repo: you need to have some sort of dependency management system to ensure that the right version is there when you build.

Dependency management systems are now a standard thing and they are integrated with CI servers very well - I would not say that the need to use it is a downside.

Depends on your target environment. Some targets/languages have great eco systems, some do not.

Subdirectories can belong to different repos. In modern IDEs like Intellij or Eclipse it's possible to work with multiple project roots in the same window (e.g. if you have a common library for microservices and want to redesign its API and make changes everywhere at once). The good thing here is that in most cases you work with just a fraction of your code and with a single project root, switching to multi-project view only in rare big reengineering tasks.

Sounds good in theory, but I'm wondering: your edit-test cycle now becomes edit-install-test?

Surely, on the QA server as CI/CD pipeline.

Not necessarily. With Java IDEs, if you have the sources you can usually modify those and the IDE knows to ignore the package manager dependencies.

To the downvoter: https://stackoverflow.com/questions/10688344/in-eclipse-m2e-...

Depends on the environment you're working in, but generally: interpreted languages typically have no problem loading a package from a temporary dev-location, compiled languages have build systems that handle that.

conda is not bad as a generic package manager for this sort of stuff (packages don't have to be Python although that's what it was initially aimed at).

> NuGET, Maven, whatever is the package manager for the language in question.

Sometimes a repo contains code written in multiple languages.

Maven, NuGET among other package managers happen to support multiple languages.

Zuul (https://zuul-ci.org/) is an open source CI/CD system that does speculative execution of CI on changes across multiple repos. So if you have a change in one repo that depends on a change in another, you can test both together before merging either (and it enforces merging in the correct order).

IME it solves the same problem that monorepos are intended to solve, but without any of the downsides.

What's more, same result can be achieved with practically every modern CI server with minor admin effort.

We wrote one in house, it works well and has useful features that nothing else has. Today I'd use conan.io, and add those useful features to that project. Our internal system works well so it is hard to find justification to tear it out, but the downside is no tool/IDE understands it, and so you can't use your favorite IDE unless your favorite IDE is the one obsolete version that we have modified to understand our tool.

Reply on news.ycombinator.com