Re: [Xen-devel] [stage1-xen PATCH v1] init: Add `glide.lock`

[Rajiv Ranganath <rajiv.ranganath@xxxxxxxxxxx>]

On Tue, Aug 15 2017 at 06:23:07 AM, Stefano Stabellini <sstabellini@xxxxxxxxxx> 
wrote:
> Thank you for the patch. Usually the description that you sent in the
> previous email is written here.
>
> I like the build.sh changes and I think introducing init/glide.yaml is a
> great idea. But I don't think that introducing init/glide.lock is
> necessary, is it? We could let glide generate it on the fly based on the
> key versioning info already specified in glide.yaml.
>
> For example, this patch already introduces:
>
>   - package: github.com/containernetworking/cni
>     version: 0.3.0
>
> to glide.yaml. Are there any other reasons for committing glide.lock to
> the repository instead of generating it?

I think the pattern of using `.lock` files to manage nested library
dependencies and semantic versioning for library APIs was initially
championed in the Ruby on Rails community. The idea has since been
adopted by Go community in Glide, Rust community in Cargo and JavaScript
community in Yarn.

Here is the link to the original discussion on whether `Gemfile.lock`
should be checked into the source tree or not. [1]

If we go by author's line of reasoning, then answer would depend on if
we consider init to be an app or a library.

Personally, I feel `init.go` is an app and it would make sense to check
in `glide.lock`.

If for some reason, in future there is a build failure due to a nested
dependency issue with dependent go libraries, then having a working
`.lock` in the git is always useful.

In anycase after sending `BUILDING.md` Fedora patches, I am also
planning on sending patches to do continuous build of `stage1-xen` in a
Fedora based docker container. That should also catch build failures
early.

Please let me know what you prefer. I can send a v2 of the patch with
just `glide.yaml`

Best,
Rajiv

[1] 
http://yehudakatz.com/2010/12/16/clarifying-the-roles-of-the-gemspec-and-gemfile/

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel