On Wed, Jul 6, 2016, at 12:34 PM, Jakob Borg wrote: > 2016-07-06 9:11 GMT+02:00 Peter Bourgon <pe...@bourgon.org>: > > You can't actually make this distinction. > > There should be a single vendor/ dir at the root of the repo. > > See https://github.com/zellyn/wtf2 for a demonstration. > > (And https://github.com/peterbourgon/wtf for context.) > > Indeed. Which means that vendoring shouldn't be used in combination > with "package at top level, cmd/ inside for commands" style repos. If > the top level package isn't the binary, the repo represents a > importable package and should not use vendoring. > > The cmd/ directory can be used for small demo programs that don't > require vendoring, but when it's something more complex it's time to > split it out into it's own repo and use a better build solution like > gb. > > I know this is an unpopular opinion, but I really think it's time to > recognize vendoring for what it is - an ugly hack to work around lack > of proper package management - and not try to make it work in all the > situations where it just doesn't...
I think the rules for Go organising public repositories to be compatible with vendoring need to be as follows: 1) repositories that do not contain a "main" package must not vendor dependencies 2) repositories that contain a "main" package must place that package at the root of the repository and may vendor external dependencies in a vendor directory at the root of the repository. Any packages included as source code within this repository should be in an internal directory at the root of the repository. I would characterise type 1 repositories as "libraries" and type 2 as "binaries" I think these 2 rules would solve all the recently reported issues with vendoring -- Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
