Hacker News new | ask | show | jobs
by gwd 754 days ago
It's certainly an interesting angle. It might have been more clear if the documentation and how-to's had explicitly used that sort of terminology: e.g., saying that step 1 of creating a project would be to create a new workspace directory for all the dependencies, then create a package directory (with a git tree) inside that.

There are certainly nice things that the current Go module system buys; but one thing I miss is that under the old system, if one of the packages wasn't working the way you expected, the code was right there already; all you had to do was to go to that directory and start editing it, because it was already cloned and ready to go. The current thing where you have to clone the repo locally, add a "go.work" to replace just that package locally to do experimentation, and then remove the "go.work" afterwards isn't terrible, but it's just that extra bit of annoying busy-work.

But being able to downgrade by simply changing the version in go.mod is certainly a big improvement, as is having the hashes to make supply chain attacks more difficult.

1 comments

You can directly edit the downloaded code when using modules, you don’t need your go.work flow at all. I often do it while debugging particularly weird bugs or to better understand library code I’m using.
One way or another, the current workflow has to be:

1. Download the code (or update the copy you downloaded last time you had an issue)

2. Redirect `go build` to use the downloaded copy rather than the upstream copy (either by modifying go.mod or go.work)

3. Do the editing

4. Undo #2

Under the old system, you just had to do #3. And sure, it's not that much work, but it's a bit more than I had to do before.

You can just edit the copy that ‘go get / go build’ download to your system. Afterwards undo the edits or re-download the module to wipe out your edits. No need to use go.work, local replaces, or anything. The files are on your disk!
Its much better to do go.work and add to your ignore. This way you won’t have to muck with go.mod and commit the file with local replaces