The main issue I see is that Provider is all about interfacing upstream (maas/ec2/etc) with the Juju abstraction. Which means that " github.com/lxc/lxd" would end up importing "github.com/juju/juju". Which from a layering perspective isn't right.
Gomaasapi is a bit unique as we're probably the only consumer. Unless you actually pushed it all the way into the MaaS upstream, it isn't going to be actively maintained and stay up-to-date. And since MaaS guys are python developers, they're unlikely to put the time in maintaining the go bindings for them, much less the Juju provider using the Go bindings. I guess my point is, either the upstream guys are actively maintaining the bindings, in which case they'll do it where the bindings live, or they aren't. While it might be slightly easier, I'd rather they tracked the go bindings more than the Provider. It fits more with what they are doing, and shouldn't have Juju-isms in their code base. John =:-> On Fri, Mar 25, 2016 at 1:12 AM, Eric Snow <eric.s...@canonical.com> wrote: > Perhaps we should move the implementation of some providers over to > the repos for the projects with which the providers interact (and then > just import them in providers/all). Then those providers would be > more likely to stay up-to-date in the face of changes in the project, > particularly backward-incompatible ones. For example: > > * provider/maas -> github.com/juju/gomaasapi/maasprovider > * provider/lxd -> github.com/lxc/lxd/lxdprovider > * ... > > or something like that. It's not a perfect solution nor a complete > one, but it should help. > > -eric > > -- > Juju-dev mailing list > Juju-dev@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev >
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
