<div dir="ltr">This is why we want to make a juju library, so we have a package that we know we need to keep backwards compatibility with.  Sure, you can vendor or pin the revision, but that doesn't help you when a new feature or fix lands and you update, and everything breaks.  If we have a library we try to keep backwards compatible, then these problems would be minimized.<br><br><div class="gmail_quote"><div dir="ltr">On Fri, Aug 12, 2016 at 1:56 PM roger peppe <<a href="mailto:roger.peppe@canonical.com">roger.peppe@canonical.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 12 August 2016 at 14:11, Nate Finch <<a href="mailto:nate.finch@canonical.com" target="_blank">nate.finch@canonical.com</a>> wrote:<br>
> No other repo should ever depend on <a href="http://github.com/juju/juju" rel="noreferrer" target="_blank">github.com/juju/juju</a>.<br>
<br>
I have to call this out. There is no decent way to use Juju from Go without<br>
depending on <a href="http://github.com/juju/juju" rel="noreferrer" target="_blank">github.com/juju/juju</a>.<br>
<br>
And backward compatibility isn't insurmountable - dependencies can be locked or<br>
vendored. Juju itself uses many non-backwardly compatible<br>
dependencies, after all.<br>
<br>
I think we should be aiming to provide a nice Go API to Juju, whether that ends<br>
up in <a href="http://github.com/juju/juju" rel="noreferrer" target="_blank">github.com/juju/juju</a> or not.<br>
<br>
  cheers,<br>
    rog.<br>
</blockquote></div></div>