Re: Move provider implementations under their related projects.

I agree with all the responses, I don't think it'd be helpful to move the providers. It's our job to track the API changes. For most of the upstreams, backwards incompatible changes are fairly infrequent. If it's difficult to track API changes, perhaps it's the same for other consumers of the

Re: Move provider implementations under their related projects.

I'm a very strong -1 on this idea. Providers are Juju specific, and the other libraries should focus on exposing a useful Go API. Tim On 25/03/16 10:12, Eric Snow wrote: > Perhaps we should move the implementation of some providers over to > the repos for the projects with which the providers

Re: Move provider implementations under their related projects.

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

Re: Move provider implementations under their related projects.

On Thu, Mar 24, 2016 at 10:12 PM, Eric Snow 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

Move provider implementations under their related projects.

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