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
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.
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.