finding the VCS root of a vendored package

[stapelberg]

Context: Debian/dh-make-golang#46

For packaging Go programs in Debian, we must separate Go libraries into individual Debian packages; vendoring is verboten as per Debian-wide policy.

The Debian tooling (specifically dh-make-golang) discovers all dependencies of a program by using vcs.RepoRootForImportPath. This doesn’t work when dependencies are vendored, as there is precisely one VCS repository into which all packages are copied.

Is there any way to programmatically determine the repo root for packages vendored using golang/dep? If not, could one be added? Recording the repo root in a JSON file would be sufficient, for example.

[sdboyer]

Hi, thanks for the issue! It's very helpful when folks bring in perspectives like these.

It seems like dep should meet your requirements just fine:

1. Really, vendoring is an implementation detail. The important thing is the lock.
2. At present, the name field of each project in the lock will correspond to a VCS repository root, because dep only works with repositories right now, and it is a requirement that "project == repo".
3. If searching the lock isn't sufficient, then given any import path, the method you'd use to deduce its project, and therefore repository root is gps.SourceManager.DeduceProjectRoot(). For correct (inter)-operation with dep, it's very important you use that function, and not any of the other ones that are out there, as some do differ subtly.

Is that enough info?

[stapelberg]

Thanks, that’s helpful. I’ll have a look later as to whether I can put the pieces together correctly.

One additional question: is there a tell-tale sign that a project uses dep as opposed to other vendoring tools? I assume we’d need to make this logic conditional on the vendoring tool which was used.

[sdboyer]

The indicator to look for would be the name and location of the files in the root directory - at minimum, a manifest.json, and possibly also a lock.json.

However, it's premature to design against such things. As the README notes, we're still in the experimental phase. We're actively planning on changing those file names - #168 - and there's a good chance they'll change again on full integration into the go toolchain.

[sdboyer]

I should note - for your purposes, creating a SourceManager just to do root deduction may be overkill. You'll have to determine whether or not that's the case, but if it is, I'd be open to creating a standalone function that does the same job as gps.SourceManager.DeduceProjectRoot().

[stapelberg]

For now, we have adopted a less involved fix on the Debian end, which is also compatible with other vendoring tools: Debian/dh-make-golang@99a2380

I’ll defer implementing dep-specific code until that becomes necessary/beneficial :). Let’s close the issue as there’s nothing left to be done. Thanks for your help!

[sdboyer]

Thanks for reaching out! Please do raise any other issues or questions as you run into them. Now's the time to make sure we consider things, and integration into system package management is not an area we've spent a ton of time on. And, clearly, such things are complicated 😄