Honestly, I'm a bit surprised that go mod edit accepts a file path at all: most of the module-mode commands operate exclusively on the main module.

What is the impact of this? Can you give some examples of use-cases where needing to change directories to run go env GOMOD or go mod edit is a significant problem?

Well basically that’s the difference between being able to use go mod edit directly and having to wrap it in a shell script that changes directories for you.

When you have a large existing $GOPATH (vendored or not) to untangle, it's a lot easier to inspect it from a fixed location, to find out what parts are already module-ready and what parts are not. Sure you can change directory right and left but if you’re not extra careful you’ll get lost in the filesystem after a few changes.

I still don't understand the use-case. You can run something like find $GOPATH/src -name 'go.mod' to find out which parts of your GOPATH tree already have module definitions.

If you want to actually examine the dependencies of your modules, the go.mod file is not sufficient: it lists only the direct and upgraded dependencies, not everything implied by the go.mod files of those dependencies. To inspect the transitive closure you need to run go list or go mod graph, and you'll need to change directory for that anyway.

On my use case we only need the direct dependencies, and definitely do not want any magic call to the internet that makes the result depend on variable internet state, so go mod edit fills the bill nicely (even though it sucks that it does not distinguish between core code and test dependencies, I should report it when I have the time).

As for find, yes that's another thing that would need adding in a shell wrapper. You can fix lots of things in shell or python wrappers, but it's much nicer when tools do the right natural thing without needing a wrapper.

go mod edit does not resolve version constraints, so it is not a suitable substitute for go get, go mod tidy, or go list. We won't be adding features in support of that substitution.

No one is asking you to add any feature, just to make existing functionality work without awkwardness.

And the whole point of go mod edit is to help integrate go in third party workflows, if you didn't want this integration to happen why did you release go mod edit in the first place?

The existing functionality is to accept a path to the go.mod file to edit. The default go.mod file, if none is provided, is the one that would be returned by go env GOMOD.