Specify which subset of dependencies to vendor during dep init

[BTBurke]

Currently, dep init generates a lock file with all dependencies in the project. In some cases, you only want to vendor certain dependencies. As an example, I'm trying to use dep with a plugin for the Caddy server.

Caddy plugins must import packages from the Caddy server, but these should not be vendored because the Caddy build server should manage these dependencies itself. In my case, the plugin is a JWT auth library, so I'd like to vendor only the dependency on the JWT validation library and leave the Caddy imports unmanaged by dep.

There might be a couple options to implement this:

1. dep init does not try to solve for dependencies on the initial run, only creating a skeleton manifest file. Then a subsequent call to dep ensure <library> would allow you to selectively include packages to be vendored.

2. dep init -x <excluded library> or dep init -i <included library> to allow the user to select which packages to vendor on the initial run.

[sdboyer]

Interesting use case, thanks for the issue!

I think we should have this covered right now. There's a system - not currently well/at all documented - that may be sufficient: in your manifest.json, you can specify ignores - an array of package names that the system will then disregard. If you list all the packages you import from Caddy, it'll ignore those packages, and any transitive dependencies only reachable through the ignored packages.

It's not something you can specify at dep init, but you can just make the changes manually, then run dep ensure.

Of course, this could create problems if your plugin actually does rely on particular versions of Caddy, and that relationship needs to be maintained. (I don't know how Caddy plugins work). If your only goal here is to control what's populated into vendor/, you may be better off with simply having a script that strips out the undesired parts.

Still, though, this is a use case I hadn't previously considered; exploring the requirements more would be handy. Could you provide some links to info about Caddy plugins, Caddy build servers, etc.?

[BTBurke]

I'll give that a try. I'm planning to write up some docs for the Caddy plugin developers so that will be helpful.

The way the plugins work is that the build server creates a custom binary by selectively importing the plugins a user chooses. The source for the base Caddy server is being updated on a different schedule from the plugins. The core APIs that the plugins rely on are stable, but it would probably break the build to vendor the whole caddy package.

More info on the plugins:
https://github.com/mholt/caddy/wiki/Extending-Caddy

[sdboyer]

@BTBurke does it seem like your case is covered, if not currently then by the new WIP spec described in #277? If so, I'd like to clean house a bit and close this out.

[BTBurke]

Yeah I think that would work great. Thanks for the update! On Thursday, April 27, 2017 at 7:49 PM sam boyer <notifications@github.com> wrote: @BTBurke does it seem like your case is covered, if not currently then by the new WIP spec described in #277? If so, I'd like to clean house a bit and close this out. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.