cmd/go: auto-find module from package import

[fwhezfwhez]

In my company, There're many packages local and saved in restricted git repo.

To import those pkgs, I'm doing like :

package main

import (
    "xxx"
)

Desperately xxx module not found. Even if I've already put xxx into $GOPATH/pkg/mod/xxx.

To fix this ,I must type

requires xxx
replace xxx ../../pkg/mod/xxx

It seems estremely bad and extra. Because once I put my projects not in GOPATH/src, the replace will changed to ../../../../path-togopath/pkg/mod/xxx. Also it doesnt support 'replace xxx $GOPATH/pkg/mod/xxx'.

Suggest full path or from root?

No, because a repo will be developed by all kinds of os, besides, remote machie and local machine might have different root format.

Thus, I hope gomodule can support auto-find pkg. It seems easy realized just like GOPATH.

• first, make sure xxx pkg is at GOPATH/pkg/mod/xxx
• import xxx

Just throw 'replace' and 'require' away on this case!

[toothrot]

It seems like this would be non-deterministic if two packages have the same name.

/cc @bcmills @jayconrod @matloob

[jayconrod]

This is probably not feasible. The module cache ($GOPATH/pkg/mod) should not be modified manually, and the go command shouldn't look anywhere else for imported packages.

Is there a reason you can't use one of the workflows for private repositories described in Private modules? In most cases, you'd name your module after the repository URL (like github.com/corp/mod or corp.example.com/mod.git), then set GOPRIVATE=git.com/corp or GOPRIVATE=corp.example.com).

[kevlar700]

Frankly the private modules information seems meant for private hosting on github rather than e.g. http over ssh localhost or local filesystem access and is a pain to understand when you should be doing a hundred other things. I feel like modules were not designed with replacing GOPATH in mind. I shall probably move to a simpler mono repo solution with sshfs or git syncing as replace seems buggy. The docs could be clearer by separating the information from modules that you don't need modules. You can just work with git pull downs into each single module folder with imports of folders within.

Edit: I have since found that gopls works far better without replace and I expect the build failure messages will be more sensible too. Module updates don't require managing http status 404 on local modules too.

[fwhezfwhez]

I hope go module has a more graceful, compatible style for some shared packages. It might look like:

module appname

go 1.13
require (
        ...
)

replace(
     ...
)

// xxx will refer to GOPATH/mod/native/xxx
// gog.xq5.com refer to GOPATH/mod/native/gog.xq5.com/yyy/zz
native(
   xxx
   gog.xq5.com/yyy/zz
)

Or, add a scheme that first find pkg from /gopath/mod/pkg/xxx, if not found, then /gopath/src/xxx, otherwise mod/native/xxx.

To profile versions of a same pkg, it can share scheme of mod. All pkgs can look like GOPATH/mod/native/[email protected]

[fwhezfwhez]

This is probably not feasible. The module cache ($GOPATH/pkg/mod) should not be modified manually, and the go command shouldn't look anywhere else for imported packages.

Is there a reason you can't use one of the workflows for private repositories described in Private modules? In most cases, you'd name your module after the repository URL (like github.com/corp/mod or corp.example.com/mod.git), then set GOPRIVATE=git.com/corp or GOPRIVATE=corp.example.com).

Private package named 'eagle'. This kind of packages have no prefix domain.By the way, I'm not author to this package and there 're many pkgs locally without domain prefix. More badly, some of them are binary-only file.

[jayconrod]

Closing this issue because it's not feasible. The module cache is just meant to be a cache; its contents are not editable.

I do agree that private and local modules are difficult to use, and we should streamline those workflows. But this kind of change to the module cache is not something we can do.

[fwhezfwhez]

@jayconrod Can go.mod support read system env value? It's like

replace local/pkg => ${GOPATH}/local/pkg

[jayconrod]

@fwhezfwhez That doesn't work at the moment, but it's probably feasible. I'd hesitate to recommend that, since a go.mod checked in by one developer would not work for someone else on their team. Relative paths within the same repo are more likely to work.

#33586 is similar though.

Also if #26640 were implemented, it wouldn't be important for directives in a go.mod.local file to work for other devs.