Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/go: accept a directory path to 'go mod edit' instead of just a file path #30173

Closed
nim-nim opened this issue Feb 11, 2019 · 8 comments

Comments

Projects
None yet
3 participants
@nim-nim
Copy link

commented Feb 11, 2019

go version go1.11 linux/amd64

go mod directory handling is a bit inconsistent

  1. it will automatically drill down to the go.mod file even if you are several directory layers over it. go mod edit -fmt -json will output the same info regardless of where you are within the module

  2. but, if you try to ask it the module info for a directory you're not in, it becomes dumb.
    go mod edit -fmt -json dirpath does not work you need to provide an exact go.mod path
    go mod edit -fmt -json dirpath/go.mod

It would be much nicer to have go mod behave the same, regardless of the implicit (you are inside the module) or explicit nature of the path in works on.

And I suppose there is some value in knowing you're at the exact module root or not, but should not this be handled by a --root flag that makes the command fail if the provided directory (implicit or explicit) is not the module root?

@nim-nim nim-nim changed the title go mod directory handling in somewhat inconsistent go mod directory handling is somewhat inconsistent Feb 11, 2019

@oiooj oiooj added the modules label Feb 11, 2019

@bcmills bcmills changed the title go mod directory handling is somewhat inconsistent cmd/go: go mod directory handling is somewhat inconsistent Feb 12, 2019

@bcmills bcmills changed the title cmd/go: go mod directory handling is somewhat inconsistent cmd/go: accept a directory path to 'go mod edit' instead of just a file path Feb 12, 2019

@bcmills

This comment has been minimized.

Copy link
Member

commented Feb 12, 2019

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.

@bcmills

This comment has been minimized.

Copy link
Member

commented Feb 12, 2019

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?

@nim-nim

This comment has been minimized.

Copy link
Author

commented Feb 12, 2019

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.

@bcmills bcmills removed the WaitingForInfo label Feb 12, 2019

@bcmills

This comment has been minimized.

Copy link
Member

commented Feb 12, 2019

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.

@nim-nim

This comment has been minimized.

Copy link
Author

commented Feb 12, 2019

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.

@bcmills

This comment has been minimized.

Copy link
Member

commented Feb 12, 2019

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.

@bcmills bcmills closed this Feb 12, 2019

@nim-nim

This comment has been minimized.

Copy link
Author

commented Feb 12, 2019

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?

@bcmills

This comment has been minimized.

Copy link
Member

commented Feb 12, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.