Currently, there is only a limited number of projects that provide a snapshot with all their dependencies (and commits). We should enforce in the guidelines that each devel subpackage must ship either available snapshot file or generate one if not provided by upstream (and ship it).
I have an experimental implementation of gofed approx-deps that approximate glide.lock file for a specific project and its commit. It generates the snapshot of all dependencies one would get if he/she run go get at the date corresponding to the commit. So far I was able to build archives from all defined packages based on the generated glide.lock and glide.yaml files.
It's essential to provide such a file since if the tooling can assume the snapshot file is available and corresponding project can be built from the enumerated dependencies, the tooling can run various advanced analysis such as API backward incompatibility detection.
This will require collaboration with all packagers (and maybe upstream) and testing. The expected benefit is automatical detection of incompatible API changes before a Go package is even updated and/or pushed into stable.
Currently, there is only a limited number of projects that provide a snapshot with all their dependencies (and commits). We should enforce in the guidelines that each devel subpackage must ship either available snapshot file or generate one if not provided by upstream (and ship it).
I have an experimental implementation of
gofed approx-depsthat approximateglide.lockfile for a specific project and its commit. It generates the snapshot of all dependencies one would get if he/she rungo getat the date corresponding to the commit. So far I was able to build archives from all defined packages based on the generatedglide.lockandglide.yamlfiles.It's essential to provide such a file since if the tooling can assume the snapshot file is available and corresponding project can be built from the enumerated dependencies, the tooling can run various advanced analysis such as API backward incompatibility detection.
This will require collaboration with all packagers (and maybe upstream) and testing. The expected benefit is automatical detection of incompatible API changes before a Go package is even updated and/or pushed into stable.