Modules and Packages

I am converting my code base to use modules but am having issues with imports of downloaded modules inside of a package inside the repo. The link to my repo is below. Whenever I try any go get command, it can’t seem to find the excelize library even though it is included within the go.mod file. I have spent about 2 hours digging at this and have been unable to solve it. I am new to modules so there is probably something I am missing.


go.mod, when created at root repository, must have associated go source codes next to it. The only Go source code I found is inside DrugRecord/DrugRecord. You might want to shift it out to root level (DrugRecord) and reinitialize go.mod.

That will do.

1 Like

go.mod is now in the root directory (I deleted and re “go mod init …” for it) and I moved the rest of the code up to that level as well since the nesting was a mistake I had been too lazy to fix. However, I still get the following after trying to run.

NOTE: I edited the links to have a space after the dot and before the com so that they are not picked up as links. Other then that, this output was copy and pasted in

go: finding module for package github. com/gorilla/mux
go: finding module for package github. com/360EntSecGroup-Skylar/excelize
go: finding module for package github. com/lib/pq
go: finding module for package github. com/sqweek/dialog
go: found github. com/gorilla/mux in github. com/gorilla/mux v1.7.4
go: found github. com/360EntSecGroup-Skylar/excelize in github. com/360EntSecGroup-Skylar/excelize v1.4.1
go: found github. com/lib/pq in github. com/lib/pq v1.6.0
go: found github. com/sqweek/dialog in github. com/sqweek/dialog v0.0.0-20200601143742-43ea34326190
# github. com/bconn98/DrugRecord/mainUtils
mainUtils\excelWriter.go:30:22: file.MergeCell(acName, “A7”, “C7”) used as value
mainUtils\excelWriter.go:31:22: file.MergeCell(acName, “D7”, “F7”) used as value
mainUtils\excelWriter.go:32:22: file.MergeCell(acName, “A9”, “F9”) used as value
mainUtils\excelWriter.go:37:29: file.SetCellFormula(acName, “G” + strconv.Itoa(i), “=G” + strconv.Itoa(i - 1) + " + C" + strconv.Itoa(i) + “- F” + strconv.Itoa(i)) used as value
mainUtils\excelWriter.go:45:33: undefined: excelize.StreamWriter
mainUtils\excelWriter.go:48:22: undefined: excelize.Cell
mainUtils\excelWriter.go:51:3: undefined: excelize.Cell
mainUtils\excelWriter.go:203:33: undefined: excelize.StreamWriter
mainUtils\excelWriter.go:231:35: undefined: excelize.StreamWriter
mainUtils\excelWriter.go:255:33: undefined: excelize.StreamWriter
mainUtils\excelWriter.go:51:3: too many errors

I expect everything before the #, but everything after that is instances of using the excelize library which is imported and appears to be caught as dependency by the modules.

Can you paste the contents of the go.mod please?

1 Like

module github. com/bconn98/DrugRecord

go 1.14

require (
github. com/360EntSecGroup-Skylar/excelize v1.4.1
github. com/gorilla/mux v1.7.4
github. com/lib/pq v1.6.0
github. com/sqweek/dialog v0.0.0-20200601143742-43ea34326190

Note: Links were edited again

It seems there is a problem with excelize package. I tried to use module in your local on my local machine by moving all nested packages in the root directory.
I checked the repo. Its readme file says we need use following command if we are using go module:

go get

When I run this command, the go.mod file has both versions 1 and 2.


go 1.14

require ( v1.4.1 v2.2.0 // indirect v1.7.4 v0.4.0 // indirect v1.6.0 v0.0.0-20200601143742-43ea34326190 v0.0.0-20200605144744-ba689101faaf // indirect v0.0.0-20200602114024-627f9648deb9 // indirect

I am getting the same compilation error as you are getting.

As per, there are a number of issues:

  1. go.mod was missing at root repository. Fixed after guidance as per Github ticket.
  2. is still importing version 1.4.1 instead of the desired v2 version. This threw a lot of missing functions error as expected. After fixing the import statement and require clause, the library code is now working.

@bconn98, you can read up to understand further. It’s worth the time for future development.

It will explains why go.mod is strict against dependency versioning, the v2 rules, and migration technique.


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