go modules - replace does not work - replacement module without version must be directory path (rooted or starting with
Asked Answered
R

3

19

I just want to use a local package using go modules.

I have these files in a folder goweb:

enter image description here

and go.mod

module goweb

go 1.12

require mypack v0.0.0

replace mypack => ./src/mypack

But go.mod complains:

replacement module without version must be directory path (rooted or starting with .

go get -u ./...

go: parsing src/mypack/go.mod: open <local path>/goweb/src/mypack/go.mod: no such file or directory
go: error loading module requirements

So I am missing some path structure here

Rossini answered 5/4, 2019 at 11:2 Comment(0)
A
20

If your app and the package it uses are part of the same go module, you don't have to add it to go.mod, you can just refer to it.

If they are not part of the same go module, then you can follow these steps:

The path you specify for the replace directive must be either an absolute path or a relative path, relative to the module's root.

So if mypack is a sibling of your module's root, you could use this:

replace mypack => ../mypack

Also, for this to work, you also have to "convert" mypack into a go module (mypack must contain a go.mod file). Run go mod init mypack in its folder.

Also check out related question: How to use a module that is outside of "GOPATH" in another module?

Abandoned answered 5/4, 2019 at 11:11 Comment(7)
Thanks, I get the same error - I updated with go get giving the same errorRossini
There is some inconsistency in the folders you gave in the question. At first you say they are inside an src folder, but in the error message there is no src folder: /goweb/mypack/go.mod. Please correct them.Abandoned
Ok, now for this to work, mypack must be a go module, it must have a go.mod file.Abandoned
See edited answer. If they are both inside the module's root, you can use it (import it) without listing it in go.mod. You only need to require and replace it if it's outside of the module's root.Abandoned
Hmm, I think I have see example of using local packages like this. HJow do you use local packages?Rossini
Please see the linked question: How to use a module that is outside of “GOPATH” in another module?Abandoned
Wait, does that mean that the replace directives will only work if all modules depending on a single module example.com/mycorepackage I must ensure that the location of this module in the fs is relative to the dependant packages in exactly the same way? I have some packages which would require replace ../../mycorepackage and some which require only ../mycorepackage. Seems a bit strange to me that replace does not resolve relative to the workspace file?!Herefordshire
P
2

I had this scenario while updating from Go 1.12 to Go 1.19; Quite a lot has changed.

I had the Protobuffer files in a separte folder called interfaces out as shown below.

Inside each microservice_x I was creating a directory called generated to hold the protoc generated artefacts.

Now I need to do a go mod init in the generated folder ; along with the replace keywords in respective go mod files

Illustrative code here https://github.com/alexcpn/go_grpc_2022 for better understanding. Please check the Make file where the build is happening.

go_grpc_2022$ tree
.
├── interfaces
│   └── microservice_1
│       └── test.proto
├── LICENSE
├── microservice_1
│   ├── generated
│   │   ├── go.mod
│   │   ├── microservice_1
│   │   │   ├── test_grpc.pb.go
│   │       └── test.pb.go
│   ├── go.mod
│   ├── go.sum
│   ├── integration_test
│   │   └── validation_test.go
│   ├── Makefile
│   ├── server
│   │   ├── go.mod
│   │   ├── go.sum
│   │   └── server.go
│   ├── test_client
│   │   └── client.go
│   └── test_server
│       ├── go.mod
│       ├── go.sum
│       └── main.go
└── README.md
Proletarian answered 12/8, 2022 at 11:33 Comment(0)
D
0

This can be resolve by knowing the directory of where the local module will be used.

./ => project folder dir.
../ => nested folder, and so on.
Diamonddiamondback answered 26/6 at 23:34 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.