{"action":"created","issue":{"url":"https://api.github.com/repos/golang/go/issues/25855","repository_url":"https://api.github.com/repos/golang/go","labels_url":"https://api.github.com/repos/golang/go/issues/25855/labels{/name}","comments_url":"https://api.github.com/repos/golang/go/issues/25855/comments","events_url":"https://api.github.com/repos/golang/go/issues/25855/events","html_url":"https://github.com/golang/go/issues/25855","id":331767976,"node_id":"MDU6SXNzdWUzMzE3Njc5NzY=","number":25855,"title":"x/vgo: check for conflicting vN/go.mod files during development","user":{"login":"bcmills","id":5200974,"node_id":"MDQ6VXNlcjUyMDA5NzQ=","avatar_url":"https://avatars3.githubusercontent.com/u/5200974?v=4","gravatar_id":"","url":"https://api.github.com/users/bcmills","html_url":"https://github.com/bcmills","followers_url":"https://api.github.com/users/bcmills/followers","following_url":"https://api.github.com/users/bcmills/following{/other_user}","gists_url":"https://api.github.com/users/bcmills/gists{/gist_id}","starred_url":"https://api.github.com/users/bcmills/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/bcmills/subscriptions","organizations_url":"https://api.github.com/users/bcmills/orgs","repos_url":"https://api.github.com/users/bcmills/repos","events_url":"https://api.github.com/users/bcmills/events{/privacy}","received_events_url":"https://api.github.com/users/bcmills/received_events","type":"User","site_admin":false},"labels":[{"id":373402289,"node_id":"MDU6TGFiZWwzNzM0MDIyODk=","url":"https://api.github.com/repos/golang/go/labels/NeedsInvestigation","name":"NeedsInvestigation","color":"ededed","default":false}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":{"url":"https://api.github.com/repos/golang/go/milestones/71","html_url":"https://github.com/golang/go/milestone/71","labels_url":"https://api.github.com/repos/golang/go/milestones/71/labels","id":3130892,"node_id":"MDk6TWlsZXN0b25lMzEzMDg5Mg==","number":71,"title":"vgo","description":null,"creator":{"login":"rsc","id":104030,"node_id":"MDQ6VXNlcjEwNDAzMA==","avatar_url":"https://avatars1.githubusercontent.com/u/104030?v=4","gravatar_id":"","url":"https://api.github.com/users/rsc","html_url":"https://github.com/rsc","followers_url":"https://api.github.com/users/rsc/followers","following_url":"https://api.github.com/users/rsc/following{/other_user}","gists_url":"https://api.github.com/users/rsc/gists{/gist_id}","starred_url":"https://api.github.com/users/rsc/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/rsc/subscriptions","organizations_url":"https://api.github.com/users/rsc/orgs","repos_url":"https://api.github.com/users/rsc/repos","events_url":"https://api.github.com/users/rsc/events{/privacy}","received_events_url":"https://api.github.com/users/rsc/received_events","type":"User","site_admin":false},"open_issues":59,"closed_issues":162,"state":"open","created_at":"2018-02-20T19:51:55Z","updated_at":"2018-06-13T17:22:57Z","due_on":null,"closed_at":null},"comments":0,"created_at":"2018-06-12T21:54:34Z","updated_at":"2018-06-13T18:07:24Z","closed_at":null,"author_association":"MEMBER","body":"Forked from discussion on https://golang.org/cl/116836.\r\n\r\n@rsc says:\r\n> The module is defined by a `go.mod` and the files in that directory and below, not by files above. If `x/v2/go.mod` exists and is OK and says it is `x/v2`, it should not matter much what `x/go.mod` says, only that it doesn't also claim to be `x/v2`. When you are working in the `x/v2/foo` directory, vgo walks up parent directories to find `x/v2/go.mod` and stops there. It doesn't sanity check all possible higher parents. So everything seems fine. Nothing looks at `x/go.mod`. Then you commit, you tag `v2.1.3`, and you push it, and THEN you find out that vgo cares about some mistake in your `x/go.mod` that is completely irrelevant to using `x/v2` (like maybe `x/go.mod` says `require blah/v4 v5.0.0` - it doesn't matter to deciding the code we want is in `x/v2`). Clearly we do have to check that `x/go.mod` does not say `module x/v2` but beyond that, vgo should be as robust as possible to problems in irrelevant files.\r\n\r\nThat seems inconsistent to me. If `x/go.mod` is irrelevant to `x/v2/go.mod` (and vice-versa) during development, then it should be irrelevant after commit too. But it cannot be irrelevant after commit, because `vgo`'s “major subdirectory” convention makes tag resolution ambiguous.\r\n\r\nConsider a sequence of events where the structure builds in the opposite direction: suppose you're working in repo root `rsc.io/x/`, and you're migrating from the “directory” convention to the “branch” convention. You start by copying everything from `x/v2/` to `x/`, including the `go.mod` file. Then you run `vgo test all`, and everything passes. Now you tag and push the commit, and it turns out that you broke `vgo get rsc.io/x@v2`: it wasn't ambiguous when you were testing locally, but now it is.\r\n\r\nIf we want to avoid that kind of failure mode, then we need one of two things: either we need to detect the conflicting `v2` module during the normal build/test cycle, or we need to ignore the conflict during tag resolution (i.e., by arbitrarily preferring either the outer or the inner `go.mod` file).\r\n\r\nAn example illustrating the undetected problem:\r\n```\r\n/tmp/v2v2$ find .\r\n.\r\n./y\r\n./go.mod\r\n./x_test.go\r\n./v2\r\n./v2/go.mod\r\n./v2/x_test.go\r\n\r\n/tmp/v2v2$ cat go.mod\r\nmodule x/v2\r\n\r\n/tmp/v2v2$ cat v2/go.mod\r\nmodule x/v2\r\n\r\n/tmp/v2v2$ vgo test all\r\nok      x/v2    (cached)\r\nok      x/v2/v2 (cached)\r\n```\r\n\r\n(CC: @myitcv)"},"comment":{"url":"https://api.github.com/repos/golang/go/issues/comments/397032618","html_url":"https://github.com/golang/go/issues/25855#issuecomment-397032618","issue_url":"https://api.github.com/repos/golang/go/issues/25855","id":397032618,"node_id":"MDEyOklzc3VlQ29tbWVudDM5NzAzMjYxOA==","user":{"login":"myitcv","id":3374574,"node_id":"MDQ6VXNlcjMzNzQ1NzQ=","avatar_url":"https://avatars1.githubusercontent.com/u/3374574?v=4","gravatar_id":"","url":"https://api.github.com/users/myitcv","html_url":"https://github.com/myitcv","followers_url":"https://api.github.com/users/myitcv/followers","following_url":"https://api.github.com/users/myitcv/following{/other_user}","gists_url":"https://api.github.com/users/myitcv/gists{/gist_id}","starred_url":"https://api.github.com/users/myitcv/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/myitcv/subscriptions","organizations_url":"https://api.github.com/users/myitcv/orgs","repos_url":"https://api.github.com/users/myitcv/repos","events_url":"https://api.github.com/users/myitcv/events{/privacy}","received_events_url":"https://api.github.com/users/myitcv/received_events","type":"User","site_admin":false},"created_at":"2018-06-13T18:07:24Z","updated_at":"2018-06-13T18:07:24Z","author_association":"MEMBER","body":"> The module is defined by a go.mod and the files in that directory and below, not by files above.\r\n\r\nThis corresponds with how I think about modules. Because after all, directories (and their subdirectories) containing modules can appear anywhere: the only things that cares that they are properly nested is `vgo list` from a parent directory (this could ensure consistency, not sure whether it currently does) or `vgo` itself when resolving modules (ultimately from a VCS), per Russ' comments.\r\n\r\nThat said:\r\n\r\n> ... then it should be irrelevant after commit too\r\n\r\nDid you mean \"after push/release\" here? \r\n\r\nBecause I think the rest of your argument gets at an issue I was thinking about earlier, namely having some sort of tooling to verify offline, pre-push (release) that your modules are nested, tagged etc as you expect. For custom import paths this would need to be combined with some sort of injection of `<meta>` tags (because again, you want to test _everything_ offline before the big \"push\"). \r\n\r\nQuite how this overlaps (or not) with the proposed \"release\" tooling I'm not sure. \r\n\r\nEqually I'm not sure how well this maps to (company) setups where there is a more involved release process."}}
{"actor":{"display_login":"myitcv"}}