Making bits of core available as separate repositories

[rcoreilly]

The core monorepo contains many useful packages that would probably be more widely used (and could e.g., be listed in the https://github.com/avelino/awesome-go page) if they were also available as separate repositories. At an earlier stage of development, we did have a fully separate collection of repositories for each such component and it was very difficult to work with, especially during the rapid development phase. We have no intention of going back to that as the primary development model.

However, it would be relatively simple to create "bare bones" separate repositories with a script that simply copies files from the core monorepo and pushes them, with any appropriate renaming etc. Periodically, these scripts could be run to update things as needed.

From a purely technical perspective, importing a package from core vs from one of these hypothetical separate repositories would be indistinguishable. Go is smart enough to only include what it needs when it builds something, so the fact that a package is part of a much larger monorepo is irrelevant.

And even the most basic packages that we'd want to make available separately would still be depending on elements from the monorepo (e.g., almost everything depends on cli, which in turn depends on a lot of base packages). We could do the string replacements to make the separate packages depend on the separate versions of other packages like cli, but making cli itself completely free of core dependencies is almost certainly not worth it.

Here's some of the packages that would be most relevant to be available separately:

• enums
• types
• cli
• math32
• svg
• gpu
• xyz

See #1379 for a related discussion.

[kkoreilly]

See #1379 (comment).

[rcoreilly]

Making the relevant parts of that comment more directly visible here:

If you take the approach of #1380 (some interrepo mirroring system), then people will randomly file issues in either one of the repositories, leading to a massive headache. If you disable issues on the smaller repo, then there is really no point in having it, and you get the exact same problem as golang.org/x, where people have to file issues on the main repo. It would be even worse than that since you wouldn't be able to have PRs in the smaller repo or else you would get massive synchronization problems. Your #1380 proposal is simply untenable, as it sacrifices a massive amount of clarity and usability in exchange for a minor improvement in discoverability.

[rcoreilly]

I was picturing a "read only" kind of mirror, with no issues or PRs etc.

Basically just a way to make the separable functionality manifestly separate, so it could be listed on awesome-go etc.

Maybe the new docs will help? we could also somehow make these separable components more obvious and discoverable at the top levels of the docs (front page etc)?

[kkoreilly]

I think you can appreciate that a read-only Git repo is a bad idea, and if people cannot file issues or PRs there, they will be very confused. Based on the way that packages and dependencies work in Go, there is no practical cost to having everything in core; the only issue is discoverability, and I don't think read-only repositories enhance discoverability much, certainly not relative to their cost.

I think if we can cogently document these packages in an accessible way, that might be sufficient. I definitely don't think abandoning the monorepo approach makes sense. We can try to see if the awesome-go people are willing to include subrepos.