Can't import a subpackage with C files

[adambabik]

What version of dep are you using (dep version)?

v0.3.1-58-g0979f44

What dep command did you run?

There is quite a lot of dependencies so maybe I will just describe the problem.

I import a project https://github.com/karalabe/hid which has a subpackage without Go files, just C files https://github.com/karalabe/hid/tree/master/hidapi/mac.

It works fine when I run dep ensure as the whole project is cloned. However, I'd like to get rid of packages I don't actually need, thus I run dep prune.

What did you expect to see?

I expect to still have the package with C code that is required for my project to compile.

What did you see instead?

The package with C code is removed and the project fails to compile as some C files are missing.

---

I totally understand that it would introduce quite a lot of complexity to follow C dependencies. However, is there any way to prevent dep prune from removing specified packages even if the do not contain Go files?

[sdboyer]

hi, welcome! excellent question.

dep prune is a sledgehammer at the moment. the plan, in large part to facilitate cases like this, is to absorb dep prune back up into dep ensure - #944 - and in doing so, provide some more granular controls over what is pruned, on a per-dependency basis. chances are that you'll have to accept an otherwise suboptimal pruning strategy for this case here, but it will preserve those C files in github.com/karalabe/hid/hidapi/mac, while still applying maximal pruning rules to other dependencies.

[adambabik]

Hey! Thanks for the response.

That's totally fine, I don't think dep should know about details like C files in some directories but more control over what's pruning would be great.

The most flexible, for my use-case, would be to explicitly preserve packages in a selected project:

[[constraint]]
  branch = "master"
  name = "github.com/karalabe/hid"
  packages = ["hidapi"]

Then, it could take the union of packages from Gopkg.toml and packages from Gopkg.lock before pruning. Just a suggestion :)

Is there any ETA for #944?

[sdboyer]

The most flexible, for my use-case, would be to explicitly preserve packages in a selected project:

This probably won't be feasible, because of how we need to make pruning interact with vendor verification - simplicity demands that we basically make pruning operate by a set of argumentless flags. More on that in this comment: #944 (comment)

still, shouldn't cause too much overhead for you.

Is there any ETA for #944?

it's open source, so i can't make any promises :) but, a couple months, maybe?

[sdboyer]

closing this in favor of #944.