[RFC] Explicitly define in glide.lock if base package is a dependency.

[sgotti]

Working on https://github.com/sgotti/glide-vc I noticed that, using the glide.lock file, it's not possible to determine if a base package with some subpackages is itself a project dependency.

For example, given:

- name: github.com/sgotti/project01    
  version: b16f2e739216b746bda87fb5b677fa672f09afb7
  subpackages:                                     
  - subpackage01

I'm not able to determine if only github.com/sgotti/project01/subpackages01 or also github.com/sgotti/project01 are needed packages.

One of the idea that came to my mind was to explicitly add "." to the subpackages if the base package is a dependency. This is what the actual PR does to trigger an initial discussion.

This of course will make the lock file slightly more verbose since every package will have a subpackage section. An improvement to make it less verbose will be to add "." only if there're other subpackages (so if only the base package is needed, no subpackage with just "." will be added).

[technosophos]

We've talked about this in the past. And maybe it's time to talk about it again.

To keep you from getting bogged down while we discuss, would the output of glide list help you solve the problem without a change to the glide.yaml file?

[sgotti]

@technosophos sorry for being late but due to a too much aggressive gmail filter I lost some github notifications.

To keep you from getting bogged down while we discuss, would the output of glide list help you solve the problem without a change to the glide.yaml file?

Yeah, I was thinking, as an alternate solution to reuse the glide list code for doing this.

[mattfarina]

@sgotti since this is machine to machine communication, would it be best to get the output of glide list as json?

[sgotti]

@mattfarina I wanted to avoid parsing the current glide list output. But if glide list will provide a json output (or have I lost something and it's already available?) I think it can be used.

[sgotti]

@mattfarina @technosophos For glide vc there's actually the need of two kind of information:

• The required packages (provided by glide list @mattfarina noticed now glide list: support json output format #365 . )
• The required packages root path (required to keep root path files or licensing information)

Now they are both provided by glide.lock but, other than what this PR tries to fix I noticed that the glide.lock can also contains unneeded subpackages if they are defined in some dependency's godep.json file. I think this is probably wanted so the solution will be to not rely on glide.lock but get the above two information somewhere.

Actually glide list just provides the first information (but I'm waiting for a json format). I can get the latter using glide's util.GetRootFromPackage but since I'm trying to avoid calling code (or I'd also just call resolver.ResolveLocal(true) to get the first information) I'd like to avoid this if possible. What about providing it in glide list json output? Other ideas?

[sdboyer]

This is gonna be happening anyway with the gps transition (a "." subpackage will be listed in the lock, when appropriate), so closing this out.