Hacker News new | ask | show | jobs
by jniedrauer 2286 days ago
This could actually be a really good solution to the maximum supported size of a Go module. If you place a go.mod in the root of your repo, then every file in the repo becomes part of the module. There's also a hardcoded maximum size for a module: 500M. Problem is, I've got 1G+ of vendored assets in one of my repos. I had to trick Go into thinking that the vendored assets were a different Go module[0]. Go would have to add support for this, but it would be a pretty elegant solution to the problem.

[0]: https://github.com/golang/go/issues/37724
1 comments
lima 2286 days ago
That does sound like a "you're holding it wrong" issue. As one of the Go team members pointed out, defining a separate module is not a hack, but the intended way of doing it.

How would a partial checkout help?

link
jniedrauer 2286 days ago
Go modules are built around git, unlike many other languages package systems. That means you don't get to pick and choose what goes into them. Imagine if you had to put an empty package.json in every (non-node) directory of your git repo to exclude it from an NPM package, or an install.py in every (non-python) directory to exclude it from a PyPI package. Multi-language repos would get ridiculous pretty quickly.
link
yencabulator 2286 days ago
> Go modules are built around git

Not really. Modules are specced based on zip files and metadata in text files. There's just support for extracting that data from git repos transparently.

Here's a slightly out of date write-up: https://research.swtch.com/vgo-module

link
lima 2286 days ago
This is only an issue if you put a go.mod file at the top level of your repo. We have monorepos with hundreds of modules.
link