On Tuesday, 21 June 2016 00:42:54 UTC+10, Chad wrote:
>
> But if you vendor, you don't really need type equality do you?
>
That sounds like a lot to give up.
> Maybe it's a design flaw when types or interfaces with unexported methods
> from the vendored pkg are visible to the end user of
But if you vendor, you don't really need type equality do you?
Maybe it's a design flaw when types or interfaces with unexported methods
from the vendored pkg are visible to the end user of the vendoring pkg.
On Sunday, June 19, 2016 at 10:52:34 PM UTC+2, Dave Cheney wrote:
>
> If you mean
If you mean forking their dependencies and rewiring their import paths, that is
a possibility. But it leaves consumers of those packages in the same position
as the thread the OP referenced because the same code is now known by two
distinct import paths breaking type equality.
--
You
Libraries can vendor in the directory "internal"?
--
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,
Nope, vendoring remains unsuitable for library authors.
On Sunday, 19 June 2016 15:14:57 UTC+10, Tyler Compton wrote:
>
> A user brought up a problem with the current vendoring setup regarding
> exposing types of a vendored dependency. There was a lot of great
> discussion and it seemed like
