separating out golang juju client from

Dimiter Naydenov dimiter.naydenov at canonical.com
Fri Dec 19 13:59:05 UTC 2014


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I think having a separate juju/api repo containing the api client as a
reusable library will definitely improve collaboration/integration
with external projects. It will require some refactoring to make it
easier to reuse, but that's also a good thing. We should split the
agent api and client api so the latter can move in a separate repo,
but leave the former in juju-core.

The apiserver should remain in juju/juju as it's closely tied with the
state package and it does not make sense to have it separately (as
long as state is also in juju-core).

However, this should not be done at the expense of more complicated
workflow: juju/api should be treated the same way as juju/juju - CI
gated merges, bot running integration / upgrade tests, RB integration.

Happy holidays ;)
Dimiter

On 19.12.2014 15:43, David Cheney wrote:
> There is no reason for the 130 (at last count) packages that 
> constitute juju-core (not counting the dozens of other packages we 
> bring in as dependencies) to live in the same repository.
> 
> If licensing is the lever that we use to break up this monolithic 
> repository, consider me +1
> 
> On Fri, Dec 19, 2014 at 11:05 PM, Kapil Thangavelu 
> <kapil.thangavelu at canonical.com> wrote:
>> 
>> 
>> On Fri, Dec 19, 2014 at 7:02 AM, Nate Finch
>> <nate.finch at canonical.com> wrote:
>>> 
>>> While I am generally for using more permissive licenses, I'm
>>> not sure how useful that might be... most significant changes
>>> require modifications to both the client and the server, or at
>>> least to libraries used by both.
>> 
>> 
>> That sort of misses the point of building apps that use juju
>> apis. Yes the two packages need to be updated together for new
>> changes same as today.
>> 
>>> 
>>> There's not that much code under cmd/juju compared to the whole
>>> rest of the repo.
>> 
>> 
>> Again its not about that code, its about building other
>> applications and facilitating integrations.
>> 
>> 
>> cheers, Kapil
>>> 
>>> 
>>> On Fri, Dec 19, 2014 at 6:03 AM, Kapil Thangavelu 
>>> <kapil.thangavelu at canonical.com> wrote:
>>>> 
>>>> one of the issues with having it in tree, means client usage
>>>> falls under the AGPL. We want to have the client used widely
>>>> under a more permissive license. I've already had
>>>> contributions to other projects n'acked due to license on our
>>>> libraries. I'd like to see it moved to a separate repo so 
>>>> that's possible. Thoughts?
>>>> 
>>>> cheers, Kapil
>>>> 
>>>> 
>>>> 
>>>> -- Juju-dev mailing list Juju-dev at lists.ubuntu.com Modify
>>>> settings or unsubscribe at: 
>>>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>>> 
>> 
>> -- Juju-dev mailing list Juju-dev at lists.ubuntu.com Modify
>> settings or unsubscribe at: 
>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>> 
> 


- -- 
Dimiter Naydenov <dimiter.naydenov at canonical.com>
juju-core team
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJUlC8pAAoJENzxV2TbLzHweucH/39/0D1WQt9pNT2yFrFb+Bt8
JNO0shKqC1Spyblqn7WKI32H7unWVcI4qF2PMYdm3wYA84Xx+ySbislIRv5fJbPo
9ex90IfKJxeEvE6Oq8guavQz6FR7Ks9BzZDnuQUt+gVeZP2QyPwu3v4963ZGIch2
vVOPwR+B9hr+eah00o8HSX2qx7ycdAxuB+yEL0Yg5gBpEcHSACcChBKiF/WAk4wc
rhEAbHDH5DdjbBmE6pJtaGavd5bs/FEsh5OgdFh5YEOSth5B9aRg9DhyzbouYr8Y
RhVu7LiewnQxpq0kyiAjl4Mjzk4m6pT7/uzzoUqPgX7Q0A6OS/bj9fXghDs7Gpo=
=PWBM
-----END PGP SIGNATURE-----



More information about the Juju-dev mailing list