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