Juju's dependencies, juju/utils and a road forward

[Tim Penhey]

Which then begs the question...

Why do we have stable gopkg.in branches depending on unstable branches?

i.e. gopkg.in/juju/charmstore.v5 depending on
gopkg.in/macaroon-bakery.v2-unstable?

This seems to smell bad.


Tim

On 04/04/18 14:17, Tim Penhey wrote:
> As a follow on...
> 
> I'd like to move juju to only use "stable" dependency branches. No more
> '-unstable'.
> 
> Tim
> 
> On 04/04/18 12:52, Tim Penhey wrote:
>> Hi folks,
>>
>> Juju has a problem with its dependencies. We have been trying to upgrade
>> a number of our dependencies recently have have been hitting road
>> blocks. Mostly because of changes to common libraries that are
>> incompatible with other libraries that we use.
>>
>> I'm pretty sure that the root of all these problems is the juju/utils
>> package. It has become a dumping ground for any common functions that
>> packages may want to share. However these common functions are changed
>> arbitrarily with only thoughts around how they impact a subset of the
>> downstreams of juju/utils.
>>
>> I think that the only sane way forward is to move all the functionality
>> we care about out of juju/utils into more cohesive, smaller, packages
>> that have meaningful names and you should be able to determine what they do.
>>
>> Where the current clashes came from were a few places.
>>  1) we wanted to change our mgo dependency
>>  2) a new file path utility function was wanted
>>  3) the debugstatus package inside utils was updated in a backward
>> incompatible way
>>
>> The root problem here is that the utils package tries to do too many
>> things. Any package called "utils" should be a warning, and we should
>> have listened to Dave Cheney when he brought this up originally.
>>
>> I think the way forward is to break up the utils package. I'd like to
>> propose that we don't add anything new to the utils package, and only
>> deletions are allowed. We create new packages that contain the
>> functionality we require, and have them be much more controlled on their
>> own dependencies.
>>
>> Thoughts?
>>
>> Tim
>>
>