2024-03-07 00:50:58 -06:00
|
|
|
# go-clone
|
2024-03-21 19:43:26 -05:00
|
|
|
5 years earlier, [gohack](https://github.com/rogpeppe/gohack) was written for the same reasons
|
|
|
|
this tool was written. gohack has a good justification for this kind of tool so here it is:
|
|
|
|
|
|
|
|
|
|
|
|
## Gohack: mutable checkouts of Go module dependencies
|
|
|
|
|
|
|
|
The new Go module system is awesome. It ensures repeatable, deterministic
|
|
|
|
builds of Go code. External module code is cached locally in a read-only
|
|
|
|
directory, which is great for reproducibility. But if you're used to the
|
|
|
|
global mutable namespace that is `$GOPATH`, there's an obvious question:
|
|
|
|
what if I'm hacking on my program and I *want* to change one of those
|
|
|
|
external modules?
|
|
|
|
|
|
|
|
You might want to put a sneaky `log.Printf` statement to find out how
|
|
|
|
some internal data structure works, or perhaps try out a bug fix to see
|
|
|
|
if it solves your latest problem. But since all those external modules
|
|
|
|
are in read-only directories, it's hard to change them. And you really
|
|
|
|
don't want to change them anyway, because that will break the integrity
|
|
|
|
checking that the Go tool does when building.
|
|
|
|
|
|
|
|
Luckily the modules system provides a way around this: you can add a
|
|
|
|
`replace` statement to the `go.mod` file which substitutes the contents
|
|
|
|
of a directory holding a module for the readonly cached copy. You can of
|
|
|
|
course do this manually, but gohack aims to make this process pain-free.
|
|
|
|
|
|
|
|
## Install go-glone
|
|
|
|
|
|
|
|
go install go.wit.com/apps/go-clone@latest
|
|
|
|
|
|
|
|
## go-glone itself
|
|
|
|
|
|
|
|
This will make a work directory and download everything needs to compile
|
|
|
|
go-clone.
|
|
|
|
|
|
|
|
go-clone --work go.wit.com/apps/go-clone
|