Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
cmd/go: check for conflicting vN/go.mod files during development #25855
Forked from discussion on https://golang.org/cl/116836.
That seems inconsistent to me. If
Consider a sequence of events where the structure builds in the opposite direction: suppose you're working in repo root
If we want to avoid that kind of failure mode, then we need one of two things: either we need to detect the conflicting
An example illustrating the undetected problem:
This 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
Did you mean "after push/release" here?
Because 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
Quite how this overlaps (or not) with the proposed "release" tooling I'm not sure.
Equally I'm not sure how well this maps to (company) setups where there is a more involved release process.
@bcmills just to pick up on the point I made above:
Just to make explicit the "disconnect" I was alluding to:
But I'll note here that we are looking at packages, not modules.
Another interesting case:
Both examples demonstrate there is (currently) no import path checking for packages "within" a module (else both would have failed).
Not sure whether this is related or not (or whether it's "broken") - just adding another data point.
referenced this issue
Jul 9, 2018
The go command today does NOT go poking around for version control system metadata in the directories where it finds local source code (except legacy "go get", which is going away), which would be required to detect this problem. I strongly believe it should continue to be ignorant of version control system metadata.
I could see an argument for walking up the file system to look for a parent go.mod that conflicts with the current one, but what if you just want to try something out and do:
We shouldn't disallow this. Or even if you are moving to a subdirectory development mode and do
to play around and see how that would work: should you have to delete all the parent files just to try something out?
The error messages for when this does happen are now dramatically clearer than they were. Let's close this until we find evidence that they're not good enough on their own.
Another good place for a check like this would be the eventual "go release", but that doesn't exist yet. I created #26420 and listed this check there.