So I wanted to update a dependency . .

[Casey Marshall]

On Thu, Aug 11, 2016 at 5:44 PM, Nicholas Skaggs <
nicholas.skaggs at canonical.com> wrote:

> This is a simple story of a man and a simple mission. Eliminate the final
> 2 dependencies that are in bazaar and launchpad. It makes juju and it's
> dependencies live completely in git. A notable goal, and one that I desired
> for getting snaps to build with launchpad.
>
> I don't feel I need to explain the pain that making a no-source change
> update to a dependency (point juju and friends to it's new location) has
> been. I've had to carefully craft a set of PR's, and land them in a certain
> order. I've encountered contention (because I have to change hundreds of
> imports), unit test issues (because juju's dependencies aren't tested when
> merged, so they can be incompatible with the latest juju without knowing
> it), and circular dependencies that require some magic and wishful thinking
> to workaround.
>
> I'm still not finished landing the change, but I hope to do so *soon*. It
> must be close now!
>
> All of this to say, I think it would be useful to have a discussion on how
> we manage dependencies within the project. From a release perspective, it
> can be quite cumbersome as dependencies are picked up and dropped. It's
> also recently made a release (And critical bugfix) really difficult at
> times. From my newly experience contributor perspective, I would really
> think twice before attempting to make an update :-) I suspect I'm not alone.
>
> I've heard ideas in the past about cleaning this up, and some things like
> circular dependencies between romulus and juju are probably best described
> as tech debt. But there also is some pain in the larger scheme of things.
> For example, we are currently hacking a patch to juju's source for the mgo
> dependency since updating the source or vendoring or any other option is
> way too painful. It's time to really fix this. Ideas?
>

My team's been chipping away at romulus and it'll be sorted out soon
enough. We've already moved the terms API client out to
github.com/juju/terms-client, and we'll be doing something similar for the
other APIs. As for the commands.. these probably need to find a better home
closer to the command base types they extend, in cmd/juju/...

One thing that occurred to me today though is most of our dependencies also
have tests (well, they should!). We don't often run *those* tests as part
of Juju CI, but you could run into some cases where some dependencies share
common dependencies, but are tested with different common dependency
versions than those specified by Juju's dependencies.tsv.


> --
> Juju-dev mailing list
> Juju-dev at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20160811/7f03112d/attachment.html>