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

go install not working when the module name is not a hostname #30227

Closed
lvlrt opened this issue Feb 14, 2019 · 5 comments
Closed

go install not working when the module name is not a hostname #30227

lvlrt opened this issue Feb 14, 2019 · 5 comments

Comments

@lvlrt
Copy link

lvlrt commented Feb 14, 2019

What version of Go are you using (go version)?

$ go version
go version go1.11.4 darwin/amd64

Does this issue reproduce with the latest release?

Yes

What did you do?

I started a go package outside of the GOPATH and used modules.
I want to use packages inside the same repo without referencing them by a remote location (e.g Gitlab)

This can be accomplished by:

$ cat go.mod
module dync

$ cat main.go
package main

import (
    "dync/" //instead of using relative path, use the name of the module
)
...

This works.

But 'go get' now gives warnings and 'go install' fails if you do want to get / install from a remote location (e.g Gitlab):

$ go get -u gitlab.com/larsveelaert/dync                                                                                                                                                                                     
package dync/folders: unrecognized import path "dync/folders" (import path does not begin with hostname)
package dync/remotes: unrecognized import path "dync/remotes" (import path does not begin with hostname)
package dync/settings: unrecognized import path "dync/settings" (import path does not begin with hostname)
package dync/syncers: unrecognized import path "dync/syncers" (import path does not begin with hostname)

$ go install gitlab.com/larsveelaert/dync
go/src/gitlab.com/larsveelaert/dync/main.go:4:2: cannot find package "dync/folders" in any of:
        /Users/lveelaert/go/src/gitlab.com/larsveelaert/dync/vendor/dync/folders (vendor tree)
        /opt/local/lib/go/src/dync/folders (from $GOROOT)
        /Users/lveelaert/go/src/dync/folders (from $GOPATH)
go/src/gitlab.com/larsveelaert/dync/main.go:5:2: cannot find package "dync/remotes" in any of:
        /Users/lveelaert/go/src/gitlab.com/larsveelaert/dync/vendor/dync/remotes (vendor tree)
        /opt/local/lib/go/src/dync/remotes (from $GOROOT)
        /Users/lveelaert/go/src/dync/remotes (from $GOPATH)
go/src/gitlab.com/larsveelaert/dync/main.go:6:2: cannot find package "dync/settings" in any of:
        /Users/lveelaert/go/src/gitlab.com/larsveelaert/dync/vendor/dync/settings (vendor tree)
        /opt/local/lib/go/src/dync/settings (from $GOROOT)
        /Users/lveelaert/go/src/dync/settings (from $GOPATH)
go/src/gitlab.com/larsveelaert/dync/main.go:7:2: cannot find package "dync/syncers" in any of:
        /Users/lveelaert/go/src/gitlab.com/larsveelaert/dync/vendor/dync/syncers (vendor tree)
        /opt/local/lib/go/src/dync/syncers (from $GOROOT)
        /Users/lveelaert/go/src/dync/syncers (from $GOPATH)

What did you expect to see?

A completed install.
Such as when building outside GOPATH.
The builder knows that 'dync' is the root of the package so it should find all subpackages under it.
Code in a repo should be agnostic from the location hosting it.

What did you see instead?

No install.
If you'd like to install the software, you need to clone it outside the GOPATH and do 'go install' there.
It would be nice for 'go install' and 'go get' to detect the packages the same way, wherever they are built.

@mvdan
Copy link
Member

mvdan commented Feb 14, 2019

There's some support for relative imports, but they're not recommended and fully supported on purpose. See #3515 and #20883.

@lvlrt
Copy link
Author

lvlrt commented Feb 14, 2019

@mvdan
I understand the argument that you'd like to be very clear on dependencies so you can copy-paste code everywhere without changing a thing.

But there is something to be said about being able to abstract code from the place it is hosted and if it is connected in a way, so you do not have to do a 'replace all' in all sources when you change repo hosting.
Just change it on 1 place.

@mvdan
Copy link
Member

mvdan commented Feb 14, 2019

I'm not arguing for or against the feature. I'm simply pointing out that if this is what you're proposing, the issue is a duplicate of #20883.

@lvlrt
Copy link
Author

lvlrt commented Feb 14, 2019

@mvdan Ok, thanks.

@mvdan
Copy link
Member

mvdan commented Feb 14, 2019

Closing as discussed above.

@mvdan mvdan closed this as completed Feb 14, 2019
@golang golang locked and limited conversation to collaborators Feb 14, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants