search

jfrog / gocenter

The Github README for JFrog Go-center. Use this for reporting issues
https://gocenter.io
Apache License 2.0
164 stars 23 forks source link

go.mod file generated by GoCenter is causing requirements resolution issues #4

Closed elioengcomp closed 5 years ago

elioengcomp commented 5 years ago

This issue was identified by user @thepudds and detailed in the #gocenter slack channel.

The go.mod file generated by GoCenter to express the author's intent is causing a different requirements tree to be resolved when compared against the behavior the user is getting when resolving from the VCS.

The problematic module is github.com/coredns/coredns@v1.1.2. It is not being served by GoCenter because the following dependency is missing github.com/ldez/go-auroradns@v0.0.0-20181019221658-b40dfcae7c41. This missing dependency cannot be processed because of an error on its mod file.

The path from the requested module to the missing dependency is: github.com/coredns/coredns@v1.1.2 -> github.com/mholt/caddy@v0.11.2 -> github.com/xenolf/lego@v0.0.0-20181211001449-b05b54d1f69a -> github.com/ldez/go-auroradns@v0.0.0-20181019221658-b40dfcae7c41

When resolving from GitHub this issue is not present. The reason is because GoCenter is generating a go.mod file for github.com/mholt/caddy@v0.11.2 and that is changing the requirements resolution behavior. Here is the go.mod file generated by GoCenter for this module:

// Generated by JFrog

module github.com/mholt/caddy

require (
    cloud.google.com/go v0.0.0-20170727181841-7a4ba9f439fb
    github.com/aead/chacha20 v0.0.0-20180709150244-8b13a72661da
    github.com/alecthomas/template v0.0.0-20160405071501-a0175ee3bccc
    github.com/alecthomas/units v0.0.0-20151022065526-2efee857e7cf
    github.com/codahale/aesnicheck v0.0.0-20140702143623-349fcc471aac
    github.com/dustin/go-humanize v0.0.0-20170228161531-259d2a102b87
    github.com/flynn/go-shlex v0.0.0-20150515145356-3f9db97f8568
    github.com/golang/mock v0.0.0-20180820161358-600781dde9cc
    github.com/golang/protobuf v0.0.0-20170726212829-748d386b5c1e
    github.com/google/uuid v0.0.0-20171129191014-dec09d789f3d
    github.com/gorilla/websocket v0.0.0-20170718202341-a69d9f6de432
    github.com/hashicorp/go-syslog v0.0.0-20170829120034-326bf4a7f709
    github.com/jimstudt/http-authentication v0.0.0-20140401203705-3eca13d6893a
    github.com/klauspost/cpuid v0.0.0-20180102081000-ae832f27941a
    github.com/lucas-clemente/quic-go v0.10.0-no-integrationtests
    github.com/mholt/certmagic v0.0.0-20181219212511-a3b276a1b44e
    github.com/miekg/dns v0.0.0-20170721150254-0f3adef2e220
    github.com/naoina/go-stringutil v0.1.0
    github.com/naoina/toml v0.1.1
    github.com/russross/blackfriday v0.0.0-20170610170232-067529f716f4
    github.com/xenolf/lego v0.0.0-20181211001449-b05b54d1f69a
    go4.org v0.0.0-20170525132722-034d17a462f7
    golang.org/x/crypto v0.0.0-20180313195238-c4a91bd4f524
    golang.org/x/net v0.0.0-20180826012351-8a410e7b638d
    golang.org/x/oauth2 v0.0.0-20170719200132-b53b38ad8a64
    golang.org/x/sys v0.0.0-20180830151530-49385e6e1522
    golang.org/x/text v0.0.0-20170714085652-836efe42bb4a
    google.golang.org/api v0.0.0-20170727025548-66dba45b0682
    google.golang.org/appengine v0.0.0-20170707203349-ad2570cd3913
    gopkg.in/alecthomas/kingpin.v2 v2.2.5
    gopkg.in/natefinch/lumberjack.v2 v2.0.0-20170531180850-df99d62fd42d
    gopkg.in/square/go-jose.v2 v2.1.4
    gopkg.in/yaml.v2 v2.0.0-20170721122051-25c4ec802a7d
)

The user provided his thoughts about the issues with this approach:

I understand the appeal of wanting to auto-create a go.mod file for a dependency that does not itself have a go.mod file, but sometimes currently creating a go.mod file requires human intervention beyond what go mod init can auto convert. In this case, the caddy author or maybe the lego author is picking a version and corresponding import path that works outside of the context of modules, and hence is a valid choice for them... but given modules now require agreement between the import path used in consumer code and the module path declared in a go.mod file being consumed, it means that particular version selection is not a valid choice with modules.

The user also suggested that we could create feature in goc to provide this capability in the client side in a less intrusive way:

Regarding GoCenter auto-creating a go.mod file for a dependency that does not itself have a go.mod file, a completely different approach that would have similar benefits but I think have fewer problems would be to try to automate this workflow, where the result is not a new go.mod file stored in GoCenter, but rather the results flow to the consumer's go.mod file on their local machine: https://github.com/golang/go/wiki/Modules#i-have-a-problem-with-a-complex-dependency-that-has-not-opted-in-to-modules-can-i-use-information-from-its-current-dependency-manager. Perhaps it could be added as an option or subcommand to goc.

elioengcomp commented 5 years ago

The go.mod file generation has been removed from GoCenter. Now, for modules that are not converted to Go Modules, GoCenter will use the same go.mod file generated by the Go client when processing them.

We have also changed the content of modules already present in GoCenter to reflect this change. Because of that, if you have fetched any of those modules from GoCenter before this change, you might run into a checksum mismatch. We have provided the complete list of modules fixed here. You can use it in case it happens to you to confim that this is the cause. In this case, you should update the content of your go.sum file to reflect the latest content.