Hypothesis: Consider the monorepo

[DRMacIver]

I have previously argued that monorepos are great and I find myself wondering whether we should be doing this for Hypothesis as well.

Here is the prompting line of reasoning:

• We will soon (in the "I am literally about to start working on this and that is what has prompted this line of reasoning") have a common rust crate that both Python and Ruby code will depend on.
• We have all these guides and documents that currently live in hypothesis-python but are really more general.
• We have all this automation set up for hypothesis-python that I ended up partially duplicating for hypothesis-ruby.
• Managing releases, testing, and deployment in tandem across multiple repos requires the use of something awful like git-submodules and even with that will not work very well.
• Questions like "How do we merge the website with the documentation?" become much easier if the documentation and the website live in one repository

Life would be much much easier on all of these points if we just had a single monorepo that we put everything in.

Sketch plan of how this would go:

• Rename hypothesis-python to hypothesis
• Move most of the package related code into a subdirectory called hypothesis-python
• Fix the inevitable build problems
• Import hypothesis-ruby into a subdirectory of the new hypothesis repo.
• Reconcile the builds and sort the inevitable build issues
• Merge the teams

Unifying the website may be a bit more problematic but also is lower priority. Still need to figure out details there. Worst case scenario though we could build it on Travis and keep the existing repository as a static site that Travis pushes to (starting doing this has a number of other nice consequences as well).

I am actually very strongly in favour of doing this, but I would like to hear arguments against before I go ahead with it.

What do people think?

[alexwlchan]

Yes.

Honestly, ever since you wrote that post, I’ve been wondering why hypothesis isn’t a monorepo and/or when we’d get around to making it one.

The big risk I anticipate is build times suffering if Ruby and Python live in the same repo – a change to the Ruby code shouldn’t trigger a Python release, and vice versa. The fix is probably more build scripts, which short circuit parts of the build matrix we aren’t using.

The compromise I’ve agreed on wellcometrust/platform is that we then have Travis run a cron job every night, which does a full build matrix, regardless of what changed that day – so PRs aren’t blocked by the backlog, but we still find breakages quickly.

[kxepal]

It's all great, but common CI services aren't very suitable for monorepos. There would be need to do a lot of tricks to avoid redundant work and make it right.

[DRMacIver]

Honestly, ever since you wrote that post, I’ve been wondering why hypothesis isn’t a monorepo and/or when we’d get around to making it one.

So far the answer has been that it effectively was one because there was only one Hypothesis project active! the website being the only notable exception.

The fix is probably more build scripts, which short circuit parts of the build matrix we aren’t using.

Yes, sorry, I meant to mention that requirement. Strongly agreed that this is needed.

It's all great, but common CI services aren't very suitable for monorepos.

They're also not very suitable for split repos when there are dependencies between them! The problem is that we want to have things like e.g. testing the latest version of the Rust core against the Python and Ruby versions.

Either way we're going to have to do build wrangling, and I think the build wrangling involved in a monorepo is going to be much easier and more robust.

[kxepal]

They're also not very suitable for split repos when there are dependencies between them! The problem is that we want to have things like e.g. testing the latest version of the Rust core against the Python and Ruby versions.

Yeah. In this case it's better to have all-in-one. Especially when you need consistently update multiple repositories.

[Zac-HD]

Count me also as strongly in favor of a monorepo :rocket:

I've actually been thinking this for the hypothesis-training course today, because I may be writing an updated version for PyCon Asia-Pacific and would like to (after testing them!) merge some interactive tutorials into our docs (see #774).

More generally, CI is likely to be a pain but it's one we know how to manage - and I'd prefer any pain in integration be felt up-front anyway!

I'd still keep distinct teams even if they don't grant new permissions though, because they're useful to \@-ping. We could also investigate CODEOWNERS files if review becomes an issue, though I'd put it off until we actually have a problem.

[DRMacIver]

I'd still keep distinct teams even if they don't grant new permissions though,

Valid point. I think I might investigate how to have a single mega team with subteams though (I think this is a thing we can do, but I'm not sure the arrows point in the right direction) - a lot of discussion is currently happening in the hypothesis-python board some of which I think should be more general.

[kxepal]

I think it may be good that team will be one for all the subprojects: this could improve overall involvement and cross teams knowledge/experience share.

[Zac-HD]

Not sure about subteams, but you can be a member of multiple teams to the same effect.

[alexwlchan]

Also, re: https://twitter.com/DRMacIver/status/981132108285579264

We should bring across all the commit history from the other repos when we connect them up.

[DRMacIver]

We should bring across all the commit history from the other repos when we connect them up.

Yes, absolutely. I'd already intended to do that, but good to be explicit about it.

[DRMacIver]

A thing I'm realising in the course of doing the initial move: I think it might be time to retire the makefile in favour of a custom top level Python script. We currently have a lot of random crap spread over bash, make, and Python in a way that I think is making our life harder than it need to be.

We could look into using an existing build runner tool that is more customisable (e.g. we could use bazel maybe), but I think our requirements are going to be weird and bespoke enough that we should just bite the bullet and write our own - all of the hard parts aren't going to be helped by having a build runner library.

[DRMacIver]

A thing I'm realising in the course of doing the initial move: I think it might be time to retire the makefile in favour of a custom top level Python script.

Gosh, remember #570? Apparently I've already had this idea...

[bukzor]

Opinions sought:

If you can implement this new monorepo in such a way that I can ignore everything but the python bit, then I'm 100% for this. Or, as long as there's a page that covers what to do for python-focused contributors, I'm perfectly happy as well.

Will I begin to need a functioning rustc to contribute fixes to the python bits of the new monorepo?

[DRMacIver]

Will I begin to need a functioning rustc to contribute fixes to the python bits of the new monorepo?

Eventually, yes, but eventually that is going to be true regardless of whether we move to a monorepo - the plan is that we will be moving to a Rust backend for almost all the implementations.

We'll certainly arrange it so that you won't, say, need a functioning Ruby runtime to contribute to the Python bit (though you will probably need a functioning Python runtime to contribute to the ruby implementation. We need to write our tooling in something and it's not going to be bash)

[bukzor]

I've been meaning to learn Rust anyway. This is a good a reason as any.

though you will probably need a functioning Python runtime to contribute to the ruby implementation

Python is installed by default on osx and linux, so I don't see that as too onerous, as long as the makefile-esque bits can run at least enough to tell us what's missing from a clean install.

👍

[kxepal]

:tada:
Shouldn't repository be renamed to hypothesis now?

[DRMacIver]

Shouldn't repository be renamed to hypothesis now?

I'll rename it once the build actually works!

[Zac-HD]

I'll rename it once the build actually works!

And edit setup.py to fix the homepage URL again :joy:

[DRMacIver]

And edit setup.py to fix the homepage URL again 😂

Technically there's nothing wrong with the old URL... GitHub will do the redirect correctly.

Sigh, but yes.