Painful imports for go modules

There are 3 directories

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

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: b@v0.0.0 requires
a@v0.0.0: unrecognized import path "a" (import path does not begin with hostname)

Ok! Some bright developer thought that every module must have a dot(.) in their module name.How lovely!

‘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/b@v0.0.0 requires
example.com/a@v0.0.0: 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)

What is going on? Why are the module local imports so complicated?

Why do you have so many modules? Modules are not packages. You’ll make your life easier by having a module at the top level of your repo and packages underneath. Everything underneath refers to that module name, and it doesn’t matter where you place it in your file system.

Just saying import “a” from some other module gives Go no clue where to find that package.

In case this isn’t useful to you, please explain what you’re trying to accomplish and why, and we can provide guidance.

2 Likes

To me Modules are independent entities which can be ‘libraries’ or a single executable component.
As I said lets say there are the following modules .

AdapterContract
MySqlAdapter
MongoDbAdapter
MyApp

In the above all 4 are modules , where any Adapter contributor is going to make the use of AdapterContract to create an adapter. Here there are two contributors MySql and MongoDb.

At the end MyApp is going to use both the created adapters and make connections to Db.

You might argue why do I need 4 modules to do so?
Precisely because I want modularity in my code.
AdapterContract is agnostic of any behaviour. It just defines ‘to be an adapter you have to look like this’.
SqlAdapter is created by some one who wants to abide to the AdapterContract same goes for MongoDb Adapter as well.
MyApp is basically a reactor. ‘I only run those who behaves like an adapter’ .

Lets say this is the examples. Is module the best approach ?

Are they separate repos with separate versioning? If you update AdapterContract, do you want to have to make a new release version of it and then a separate commit in MyApp to use the new version? Do you want MyApp, MySqlAdapter and MongoDbAdapter to all be able to use different versions of AdapterContract? If the answer to all of this is “yes”, the those are modules.

If you answered “no” to any of that then I’m pretty sure those are all just packages in the same overarching module, and that’s where I would start until it’s proven wrong.

Yeeah they are in different repos. Different team working on each of these . I would also want to open up contracts tomorrow to my vendors.so that they can contribute different adapters.Clearly they are modules.

Sounds like they are, then you just need reasonable go-gettable module paths, or you will need to use replace in go.mod to point to them.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.