-
Notifications
You must be signed in to change notification settings - Fork 374
Migration from 'go dep' to 'go mod' #1331
Comments
@umarcor you can work around this issue for quicker rebuilds using
A simple example A more comprehensive post https://medium.com/@petomalina/using-go-mod-download-to-speed-up-golang-docker-builds-707591336888 |
@umarcor thanks for starting this thread. @umarcor @mcastelino |
Nevemind, I found go modules are targeted to be fully stable in Go 1.13, targeted to be released August 2019. |
@mcastelino, sure. But, i) that's somehow equivalent to having
Neither of those options guarantee that the developer is using the latest compatible versions of the dependencies. It does guarantee that compatible versions are used, which were the latest when 1. the last commit was pushed to the repo; or 2. the docker image was built. The developer needs to execute In CI environments that support cache (such as Travis), the startup time is similar between downloading the dependencies in the docker images, doing so in the git repo, or retrieving the cache.
With option 3, kata-containers would not need to host (probably multiple versions) of the dependencies. Yet, the build environment would be reproducible. Precisely,
Now, I want to execute four builds of an app that depends on A.2 and B.1:
When building on the host, all of these might be valid, each in it's own use case:
How can the user define which of the six approaches above is used? I'm not sure about this being clearly defined. Mostly because 'compatibility' of versions which are already available in the environment is not checked according to a specific commit SHA. I.e., if semantic versioning is supported, multiple commits on top of the initially defined reference can be used. This makes it difficult to decide in the example above if
I think that the first step is to evaluate whether Meanwhile, it is possible to keep a branch just a single commit ahead of master (see script in the first comment above). Travis keeps the cache of each job independent. Then, it is possible to 'permanently' evaluate both approaches in parallel. Two points to consider:
|
@mcastelino upon further reading, yes, the reference you provided is definitely useful to accelerate multiple consecutive executions of |
@umarcor I think that as long as we don't run into issues with Kata repositories, and that we can achieve proper vendoring through |
+1 for migrating to |
I think we can move to mod when we switch to golang 1.13. At that time, go moduls will be on by default. |
Add the go.mod file required for converting runtime to go module. This file is generated with `go mod init` using the existing Gopkg.lock and running a `go build` followed by `go test`. Fixes kata-containers#1331 Signed-off-by: Archana Shinde <archana.m.shinde@intel.com>
Add the go.mod file required for converting runtime to go module. This file is generated with `go mod init` using the existing Gopkg.lock and running a `go build` followed by `go test`. Fixes kata-containers#1331 Signed-off-by: Archana Shinde <archana.m.shinde@intel.com>
is any news about this issue? |
Coming from #1152:
Let's continue here, to avoid getting @Pennyzct's PR dirtier.
Description of problem
This is neither a problem nor a requirement, because
dep
is not deprecated, yet. Certainly, it is still actively maintained (golang/dep#2052). Nonetheless, asgo mod
will eventually cease to be experimental, it is worth considering the implications.Expected result
dep
orgo mod
, at least until the baseline supported version in kata is above 1.11. Consider removingdep
support afterwards.vendor
from the repository.Actual result
dep
is supported.vendor
repository is checked in the repo and it must be explicitly updated. See #1152, community#88 and community#89.So, regarding
I said I was asking because of curiosity since I don't really understand how
go mod
is expected to work. I see that it always works in clean environments (such as CI jobs), but when used in a machine with other golang packages, it freaks out easily. Precisely, the behaviour that I have seen is the following:go.mod
is retrieved.Moreover,
go mod
allows to generate avendor
directory, but it is not honoured. I.e., I would expect it to search for dependencies in common paths (/go
,~/go
,GOPATH
) and save additional clones in thevendor
only when there is some conflict. Then, whengo build
orgo run
is executed, it would use the versions invendor
and, if not present, it would search in the common paths.What is happening instead is that you can copy absolutely all the dependencies to
vendor
and then tell go tools to use it exclusively. This is quite nonesense, because it effectively treats each repository as a completely independent project and the same dependencies are duplicated unnecessarily. At this point, I don't know if there is any benefit over using git submodules, provided that all the go dependencies are available as git repos.Therefore, an 'easy' workaround is to just use a
golang:alpine
container and build the binaries withCGO_ENABLED=0 go build -a
. This allows to execute each build in a clean environment, so there is no conflict with other projects in the host. The main disadvantage of this approach is that all the dependencies are downloaded each time a container is started, unlessvendor
is used exclusively.Ideally, checking
vendor
into the repo should not be required neither withdep
nor withgo mod
. Thevendor
directory should be a local temporal resource that can be 'generated' unequivocally withgo.mod
,Gopkg.lock
and/orGopkg.toml
.Last, the behaviour of
go mod
is different if the repository is inside or outside of theGOTPATH
.Anyway, the 'clean' approach to migrate from
dep
togo mod
should be as 'simple' as:Summarizing, @grahamwhaley, @sboeuf, I am interested on the discusion, on hearing your thoughs, and on seen how a project like this handles this specific issue (provided that dependency management in golang is a flaw in the language/ecosystem). Nevertheless, I can sure open PRs applying the script above to the repos you deem appropriate.
The text was updated successfully, but these errors were encountered: