CODEWITHSUNDEEP
gogo-modules
deepg
deepg

Reputation: 403

How to resolve transitive dependencies of local modules

Inside some random folder, there are 3 folders a, b, c. Each of these folders contain a mod file.

The mod files contains are the following .

go.mod inside a

module a

go 1.13

go.mod inside b

module b
go 1.13
require a v0.0.0
replace a v0.0.0 => ./../a

go.mod inside c 

module c
go 1.13
require b v0.0.0
replace b v0.0.0 => ./../b

Module b throws no error. But module c throws error

go: [email protected] requires
[email protected]: unrecognized import path "a" (import path does not begin with hostname)

Every module must have a dot(.) in their module name.

'Some random folder' changes to example.com. Now example.com named folder contains all the a.b.c folders. Here is how the modules look now

Module A looks like 

module example.com/a
go 1.13

Module B looks like

module example.com/b
go 1.13
require example.com/a v0.0.0
replace example.com/a v0.0.0 => ../a

Module C looks like

module example.com/c
go 1.13
require example.com/b v0.0.0
replace example.com/b v0.0.0 => ../b

Too bad! Error!

go: example.com/[email protected] requires
example.com/[email protected]: unrecognized import path "example.com/a" (https fetch: Get 
https://example.com/a?go-get=1: dial tcp 208.73.210.202:443: connect: connection refused)

How does the transitive dependency for local modules work? Why is Go hitting example.com to bring the modules? What is going on?

Upvotes: 1

Views: 3762

Answers (1)

icza
icza

Reputation: 418455

Go Wiki: Modules: go.mod

exclude and replace directives only operate on the current (“main”) module. exclude and replace directives in modules other than the main module are ignored when building the main module. The replace and exclude statements, therefore, allow the main module complete control over its own build, without also being subject to complete control by dependencies. (See FAQ below for a discussion of when to use a replace directive).

And also in Command go: The main module and the build list:

The main module's go.mod file defines the precise set of packages available for use by the go command, through require, replace, and exclude statements. Dependency modules, found by following require statements, also contribute to the definition of that set of packages, but only through their go.mod files' require statements: any replace and exclude statements in dependency modules are ignored. The replace and exclude statements therefore allow the main module complete control over its own build, without also being subject to complete control by dependencies.

Package a is not found when building the module c, so the go tool tries to resolve it, tries to download it. That's why it tries to interpret the package name as something that should start with a host name.

You do not need to rename package a to example.com/a, but you must add a replace directive to c's go.mod where you tell where the package a is located.

Upvotes: 3

Related Questions