proposal: cmd/go: allow serving module under the subdirectory of git repository #34055
Comments
For now I'm redirecting |
I might also just switch to moving the real code into the subdir |
So unfortunately people were getting confused that the mod path didn't resolve directly to the root of the repo and I tried the type alias thing but in the docs it links directly to the other package instead of inlining the docs so I'd have a decent amount of duplication if I copied the types and translated between them. |
It's unclear what bug is being raised in this issue and/or what proposal to the go command is being suggested. I'm going to close this bug, but check out https://github.com/golang/go/wiki/Questions as it may provide a good avenue to continue this discussion. |
Apologies for the confusion. To clarify, I'm trying to serve a subdir of my repository https://github.com/nhooyr/websocket under the import path |
I've got same issue. I have project with migrations, protobuf files and other infrastracture files. |
I have the same issue. @katiehockman Please reopen, this is a legitimate issue that a lot of people are experiencing. A brief proposal to fix the issue would be to add an optional fourth parameter to
This would import the |
/cc @bcmills @jayconrod |
See previously #33562. |
The subdirectory rule is not working. Does anyone find it working with "go version go1.13.6 darwin/amd64"? Thanks |
We (Apache Thrift) are bitten by this issue as well. For Apache Thrift project, the only part that would be imported by others is
If we move |
Adding to proposal minutes. The basic problem is to be able to use a meta tag to redirect not just to a Git repo but to a subdirectory within a Git repo where the module root lives. That could be an extra field in the meta tag form, but of course it would not be safe to use until the change trickled to older versions of Go (or you assume those older versions are all using the proxy). |
This proposal has been added to the active column of the proposals project |
Note that this proposal wouldn't help with
You can make tags for the module by calling the tags See https://golang.org/ref/mod#vcs-version. In general, I support this proposal. When using A question is what the applicable tags would be. I think people would expect and want unprefixed tags to work judging from the described use cases, but since different modules might point to different subdirectories, prefixed tags would probably be more consistent. |
I agree. I think prefixed tags are the only viable option. |
While I can see the prefixed tags could be useful in some use cases, for Apache Thrift we would really prefer to be able to use the global git tag. The reason is that for Apache Thrift the releases are always global: it includes the compiler, and libraries for all the supported languages. So for go library, people really need to use the matching version with the compiler (e.g. always use May I suggest that we use the global tag as a "fallback"? e.g. if there's no prefixed tags matching the go.mod path, fallback to use the global tag instead? I can see there could be a potential issue of a project used to not use prefixed tags, so we fallback to global tag, then at some point they started to use prefixed tags, and then we could have two, conflicting |
@fishy, fallbacks are not viable because they could result in time-dependent meanings of versions for a given repo. If we start out with only a Given that it's straightforward to for module authors to duplicate tags with prefixes if desired, it seems better to avoid introducing that ambiguity. |
@bcmills did you see the part that I suggested to add suffix for fallback global tags to resolve that issue? tag it twice is "trivial", sure, but it's also some special thing we need to do for go library. thrift is a project supporting tens of languages, and no other language requires this special treatment like go does (if we move forward to only support prefixed tags). |
I am not saying I like fallbacks, but this is not actually that much of a blocker. git tags can change, so we can treat adding a prefixed tag for an existing unprefixed tag the same way we treat changing a tag: it's a mistake and it will be blocked by the Checksum Database. A bigger problem is unprefixed tags leaking into all modules which might not be intended, and inconsistency with the current behavior of modules in subdirectories which we can't change. |
I think an auto added suffix can mitigate that issue to some degree? |
The original proposal was about being able to make a custom domain like nhooyr.io/websocket be able to redirect to a subdirectory of a Git repo. That's still something we can do and it doesn't seem too bad to do it. It is definitely the case that we can't make github.com/apache/thrift somehow redirect to github.com/apache/thrift/lib/go/thrift, both due to ambiguity issues and because there is no control over that rule. (Maybe if GitHub let you edit the <meta> tag we could relax the rule and respect the meta tag, but right now the hard-coded rule in cmd/go matches GitHub's hard-coded <meta> tag.) But is the custom domain version still worth doing? |
This seems feasible. Two thoughts about remaining issues. First, what should the
This would work: the Second, what should the version tags look like. I agree with @bcmills: we should avoid letting multiple tags represent the same version; it leads to too much confusion. #32945 also introduces to this problem, and if we accepted both, we'd have four possible tags for each version. I'm not really convinced that creating a Go-specific tag is that much of a burden; I'd expect each language would have its own idiosyncrasies, like creating and uploading a release artifact. We already have the convention that if a module is rooted in a subdirectory of a repository, its version tags must have that subdirectory as a prefix (not including a major version subdirectory if any). So for the module above, the tags would be:
If there were another module
|
Feel free to yell and throw chairs at me:
|
I went through all messages I would like to clarify that this issue points to this scenario
P.S.While writing this I was decide that to have the go.mod in the root is not incorrect. P.S.SActually if you import one package from the repository with root go.mod then the go.sum of package importer will import all |
Apologies, but this is not actually a standard layout. If you look at any of the github.com/golang repos, they have no "pkg" directory. The link https://github.com/golang-standards/project-layout is in the github.com/golang-standards org, which I've never heard of before today. (We do tend to put commands in cmd/, but that's not relevant here.) It's fine if you want to put Go code in pkg/. It just means that pkg will appear in your import path. Moving general packages to a separate repo sounds like a reasonable solution. |
OK, so it sounds like people are on board with adding a new space-separated field in the metadata, and then having the module version tag include the subdirectory name. So:
tagged in the repo as Do I have that right? |
If you head to https://github.com/nhooyr/websocket presently, you'll get blasted with a massive root directory listing, mostly due to all the Go files. It's obnoxious.
Compare that to https://github.com/nhooyr/websocket/tree/067b40e227d0d6af9e399c1efe0dd80efae1b79f where the Go module has been moved to the subdirectory
./mod
inside the repository.See nhooyr/websocket#136
So I want to move the Go module to the subdirectory
./mod
inside the repository and serve that subdirectory for thenhooyr.io/websocket
import path but it doesn't look like there is an easy way to do that.The go-import meta tag only allows me to specify the import path of the repository, which in this case would make it
nhooyr.io/websocket/mod
which is nasty. I want to serve the subdirectory directly undernhooyr.io/websocket
. Looks like I can do this with the new mod vcs to the go-import tag but then I have to run my own module server which I want to ideally avoid.Is this something that would be considered or is already possible?
The text was updated successfully, but these errors were encountered: