4 ms·
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 t
by jniedrauer 7y 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 https://github.com/golang/go/issues/37724
- lima 7y agoThat 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?
- jniedrauer 7y agoGo 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.
- lima 7y agoThis 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.
- yencabulator 7y 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 https://research.swtch.com/vgo-module