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

Jump to bottom

cmd/go: skip checking of go-import meta tags if replace exists for custom domain #26749

Closed
myitcv opened this issue Aug 1, 2018 · 4 comments
Closed

cmd/go: skip checking of go-import meta tags if replace exists for custom domain #26749

myitcv opened this issue Aug 1, 2018 · 4 comments
Labels
FrozenDueToAge modules

Comments

@myitcv
Copy link
Member

myitcv commented Aug 1, 2018

Please answer these questions before submitting your issue. Thanks!

What did you do?

At the time of writing, honnef.co is down/returning 50X errors.

So I tried to side-step this by adding a number of replace directive to the Github VCSs where the respective modules map.

e.g.

replace (
        honnef.co/js/dom => github.com/dominikh/go-js-dom v0.0.0-20180323154144-6da835bec70f
        honnef.co/go/js/util => github.com/dominikh/go-js-util v0.0.0-20150216223935-96b8dd9d1621
        honnef.co/go/js/xhr => github.com/dominikh/go-js-xhr v0.0.0-20150307031022-00e3346113ae
)

What did you expect to see?

I'd hoped to see that cmd/go did not try and hit honnef.co with URLs like https://honnef.co/go/js/dom?go-get=1 in order to determine the module root.

What did you see instead?

go: honnef.co/go/js/dom@v0.0.0-20180323154144-6da835bec70f: unrecognized import path "honnef.co/go/js/dom" (parse https://honnef.co/go/js/dom?go-get=1: no go-import meta tags ())

Is it reasonable to assume that if I have a replace directive path that matches a require that there is no module root checking required? Custom domain or otherwise I guess (although in this case it is a custom domain)?

I seem to remember some discussion from Russ about this in an issue/CL, but might be mistaken in that.

Does this issue reproduce with the latest release (go1.10.3)?

n/a: testing with tip

System details

go version devel +6b9c782f9f Wed Aug 1 00:57:00 2018 +0000 linux/amd64
GOARCH="amd64"
GOBIN="/home/myitcv/.mountpoints/x/src/myitcv.io/.bin"
GOCACHE="/home/myitcv/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/myitcv/.mountpoints/x"
GOPROXY=""
GORACE=""
GOROOT="/home/myitcv/gos"
GOTMPDIR=""
GOTOOLDIR="/home/myitcv/gos/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/myitcv/.mountpoints/x/src/myitcv.io/go.mod"
GOROOT/bin/go version: go version devel +6b9c782f9f Wed Aug 1 00:57:00 2018 +0000 linux/amd64
GOROOT/bin/go tool compile -V: compile version devel +6b9c782f9f Wed Aug 1 00:57:00 2018 +0000
uname -sr: Linux 4.15.0-29-generic
Distributor ID:	Ubuntu
Description:	Ubuntu 18.04.1 LTS
Release:	18.04
Codename:	bionic
/lib/x86_64-linux-gnu/libc.so.6: GNU C Library (Ubuntu GLIBC 2.27-3ubuntu1) stable release version 2.27.

/cc @rsc @bcmills
@myitcv myitcv added the modules label Aug 1, 2018
@bcmills
Copy link
Contributor

bcmills commented Aug 1, 2018

Is it reasonable to assume that if I have a replace directive path that matches a require that there is no module root checking required?

Yes, but we still need to decide what version it is that we're replacing: if you require the current module from outside, it will still pick up a requirement at the original honnef.co path and need some version to run MVS on.

Did you specify a version to be replaced in the go.mod file? (Perhaps v0.0.0?)

Perhaps we should assume pseudo-version vM.0.0-00000000000000-000000000000 when we try to look up versions for replaced modules, but it's a little odd to automatically add a requirement on a version that doesn't actually exist.

@myitcv
Copy link
Member Author

myitcv commented Aug 1, 2018

I should really have provided more context in my go.mod, apologies. Here's a slimmed down version, with master as the replacement "version" (i.e. this is pre me running the go command where that would get resolved):

module myitcv.io

require (
        honnef.co/go/js/dom v0.0.0-20180323154144-6da835bec70f
        honnef.co/go/js/util v0.0.0-20150216223935-96b8dd9d1621 // indirect
        honnef.co/go/js/xhr v0.0.0-20150307031022-00e3346113ae
)

replace (
        honnef.co/js/dom => github.com/dominikh/go-js-dom master
        honnef.co/go/js/util => github.com/dominikh/go-js-util master
        honnef.co/go/js/xhr => github.com/dominikh/go-js-xhr master
)

The versions in the require directives are those that previously successfully resolved (unsurprisingly they match the commits in the description of this issue). But, and I think this is the point you are hinting at, it could equally be that these require directives did not previously exist.

As you can see, I'm using version-agnostic replace directives.

Perhaps we should assume pseudo-version vM.0.0-00000000000000-000000000000 when we try to look up versions for replaced modules, but it's a little odd to automatically add a requirement on a version that doesn't actually exist.

Possibly in the case that a require directive (I keep using that word "directive", is it correct??) doesn't already exist.

@bcmills
Copy link
Contributor

bcmills commented Aug 1, 2018

I seem to remember some discussion from Russ about this in an issue/CL

#26241?

@myitcv
Copy link
Member Author

myitcv commented Aug 1, 2018

Ah, thank you. My searches were clearly not good enough. I'll close this issue in favour of #26241

@myitcv myitcv closed this as completed Aug 1, 2018
@golang golang locked and limited conversation to collaborators Aug 1, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge modules
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@myitcv @bcmills @gopherbot