If glide.lock package has empty subpackages, glide-vc cleans subdirs of the repo.

[chancez]

Ex given a glide.lock (not complete, trimmed to demonstrate):

hash: a92787bfb8b070e832ea4315aa20b5220ac3c530383ee531462dc75c1478c7fc
updated: 2016-08-29T11:04:56.268632692-07:00
- name: github.com/coreos/pkg
  version: 160ae6282d8c48a33d8c150e4e4817fdef8a5cde
  subpackages:
  - flagutil

Glide-vc will clean all things that are not
github.com/coreos/pkg/flagutil as expected:

glide vc --dryrun --only-code | grep coreos\/pkg
Removing unused file: github.com/coreos/pkg/.gitignore
Removing unused file: github.com/coreos/pkg/.travis.yml
Removing unused file: github.com/coreos/pkg/CONTRIBUTING.md
Removing unused file: github.com/coreos/pkg/DCO
Removing unused file: github.com/coreos/pkg/MAINTAINERS
Removing unused file: github.com/coreos/pkg/README.md
Removing unused file: github.com/coreos/pkg/build
Removing unused dir: github.com/coreos/pkg/capnslog
Removing unused dir: github.com/coreos/pkg/cryptoutil
Removing unused dir: github.com/coreos/pkg/dlopen
Removing unused dir: github.com/coreos/pkg/health
Removing unused dir: github.com/coreos/pkg/httputil
Removing unused dir: github.com/coreos/pkg/multierror
Removing unused dir: github.com/coreos/pkg/netutil
Removing unused dir: github.com/coreos/pkg/progressutil
Removing unused file: github.com/coreos/pkg/test
Removing unused dir: github.com/coreos/pkg/timeutil
Removing unused dir: github.com/coreos/pkg/yamlutil

Given the following glide.lock I would expect every subpackage in github.com/coreos/pkg to be retained:

hash: a92787bfb8b070e832ea4315aa20b5220ac3c530383ee531462dc75c1478c7fc
updated: 2016-08-29T11:04:56.268632692-07:00
- name: github.com/coreos/pkg
  version: 160ae6282d8c48a33d8c150e4e4817fdef8a5cde

However, it won't keep any packages within github.com/coreos/pkg in this case:

glide vc --dryrun --only-code | grep coreos\/pkg
Removing unused file: github.com/coreos/pkg/.gitignore
Removing unused file: github.com/coreos/pkg/.travis.yml
Removing unused file: github.com/coreos/pkg/CONTRIBUTING.md
Removing unused file: github.com/coreos/pkg/DCO
Removing unused file: github.com/coreos/pkg/MAINTAINERS
Removing unused file: github.com/coreos/pkg/README.md
Removing unused file: github.com/coreos/pkg/build
Removing unused dir: github.com/coreos/pkg/capnslog
Removing unused dir: github.com/coreos/pkg/cryptoutil
Removing unused dir: github.com/coreos/pkg/dlopen
Removing unused dir: github.com/coreos/pkg/flagutil
Removing unused dir: github.com/coreos/pkg/health
Removing unused dir: github.com/coreos/pkg/httputil
Removing unused dir: github.com/coreos/pkg/multierror
Removing unused dir: github.com/coreos/pkg/netutil
Removing unused dir: github.com/coreos/pkg/progressutil
Removing unused file: github.com/coreos/pkg/test
Removing unused dir: github.com/coreos/pkg/timeutil
Removing unused dir: github.com/coreos/pkg/yamlutil

Using --keep has no useful effect here.

[sgotti]

@chancez Thinking about this I'm not sure that no subpackages in glide.lock means that all the subpackages should be kept. I think that only the root packages should be kept (like glide-vc is doing now) and the glide.lock should always contain every needed subpackage.

Sorry but I'm a little bit in an hurry and hadn't time to verify/test this. Do you have a simple reproducer? (or I'll try it tomorrow).

[chancez]

@sgotti If no subpackages are listed, glide includes the entire repo into the vendor directory. This is easy, add the following snippets above to any glide.lock and run glide.install, you'll see it installs all of the packages within github.com/coreos/pkg into vendor. If you use glide-vc you'll see nothing is kept.

[sgotti]

@chancez glide always includes the full repository in the vendor directory (see also the glide-vc readme and this post: http://engineeredweb.com/blog/2016/go-why-not-strip-unused-pkgs/), that's the reason why glide-vc was born (to remove unneeded packages).

So (but will verify this tomorrow) if a subpackage is not listed in glide.lock this means that glide doesn't consider it as needed. If you have a specific problem and a simple repository with a glide.yaml I could test it. You can also use glide list to get a list of the packages glide thinks are needed.

[chancez]

Hmm let me think about this more.