-
Notifications
You must be signed in to change notification settings - Fork 58
Go modules - unable to get a sub-package to work #33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Per the official wiki https://github.com/golang/go/wiki/Modules#gomod
|
This is part of a consistency exercise for #33 - the go mod version now matches the Go version in the Dockerfile. This was queried with @bmcstdio, but we got no response on his PR. #24 (comment) Signed-off-by: Alex Ellis (OpenFaaS Ltd) <[email protected]>
@LucasRoesler can you highlight what you want us to take from that quote, it isn't obvious to me what I'm supposed to get from it. |
|
this means nested uses of replace will not work |
There is an alternative without Go modules which appears to work in Docker, but does not work properly on the local system. In the repo, I can set this relative import, and then turn off package function
import (
"net/http"
"handler/function/handlers"
)
func Handle(w http.ResponseWriter, r *http.Request) {
handlers.Echo(w, r)
} Setting Given the promise of Go modules and enthusiasm from the community for them, we need to find a way to make this work. What ideas to people have? |
So here is a hacky suggestion, can we offer a MOD_REPLACE.txt that can be injected into the root-level main.go? By default it'd be:
Then users could write into GO_REPLACE.txt like follows:
And the final Go.mod file for main.go would have that appended. |
Go sub-modules do not work with this template, because the of limitations on how local imports and the "replace" word works in Go modules. You can only use "replace" in the root-level module i.e. "main.go" https://github.com/golang/go/wiki/Modules#gomod This patch was tested with the following repo: [email protected]:alexellis/golang-middleware-relative-import.git Signed-off-by: Alex Ellis (OpenFaaS Ltd) <[email protected]>
Go sub-modules do not work with this template, because the of limitations on how local imports and the "replace" word works in Go modules. You can only use "replace" in the root-level module i.e. "main.go" https://github.com/golang/go/wiki/Modules#gomod This patch was tested with the following repo: [email protected]:alexellis/golang-middleware-relative-import.git * Documentation in the README has been updated * Tested e2e and with a local "go test" in GOPATH with modules turned on and Go 1.13 * Updated copy commands in Dockerfile so that they use a faster mechanism, vs creating a new container step to chown (must be tested with buildkit before merging, since buildkit did not like this approach in the past when running as a restricted user at runtime) Signed-off-by: Alex Ellis (OpenFaaS Ltd) <[email protected]>
Fixes: #33 Go sub-modules do not work with this template, because the of limitations on how local imports and the "replace" word works in Go modules. You can only use "replace" in the root-level module i.e. "main.go" https://github.com/golang/go/wiki/Modules#gomod This patch was tested with the following repo: [email protected]:alexellis/golang-middleware-relative-import.git * Documentation in the README has been updated * Tested e2e and with a local "go test" in GOPATH with modules turned on and Go 1.13 * Updated copy commands in Dockerfile so that they use a faster mechanism, vs creating a new container step to chown (must be tested with buildkit before merging, since buildkit did not like this approach in the past when running as a restricted user at runtime) Signed-off-by: Alex Ellis (OpenFaaS Ltd) <[email protected]>
I've opened #34 which seems to work and provide a workable solution. @LucasRoesler @stefanprodan did you have any other ideas to unblock this, or anything else we should try? |
Fixes: #33 Go sub-modules do not work with this template, because the of limitations on how local imports and the "replace" word works in Go modules. You can only use "replace" in the root-level module i.e. "main.go" https://github.com/golang/go/wiki/Modules#gomod This patch was tested with the following repo: [email protected]:alexellis/golang-middleware-relative-import.git * Documentation in the README has been updated * Tested e2e and with a local "go test" in GOPATH with modules turned on and Go 1.13 * Updated copy commands in Dockerfile so that they use a faster mechanism, vs creating a new container step to chown (must be tested with buildkit before merging, since buildkit did not like this approach in the past when running as a restricted user at runtime) Signed-off-by: Alex Ellis (OpenFaaS Ltd) <[email protected]>
Uh oh!
There was an error while loading. Please reload this page.
Description
When adding a sub-package to a function using golang-middleware and Go modules, I'm unable to get it to build. The unit tests fails immediately, then the go build fails if the test step is commented out.
Sample repo
https://github.com/alexellis/golang-middleware-relative-import
The top-level entry-point is main.go
main.go is a module and references a folder "function" which is also a module.
The basic path of a function handler with no other packages seems to work without Go modules, but when adding a sub-package i.e.
handlers
and referencing that, the tests and build fail.main -> function -> handlers (sub-package)
This should have been a basic happy path scenario tested in #24, so I'm surprised to see that this didn't work. Pinging the people who tested / reviewed the PR.
@ewilde @LucasRoesler @bmcstdio @jonatasbaldin @stefanprodan
I imagine this is the same issue for
go
andgolang-http
also.When using dep and a vendor folder this can be worked-around so that it works in the container, but not on a local system. The ideal resolution would have OpenFaaS functions with sub-packages working well in an IDE with highlighting and goreturns etc all working fine, and also working in a
docker build
.The text was updated successfully, but these errors were encountered: