So I wanted to update a dependency . .

[Nicholas Skaggs]

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20160811/089ab762/attachment-0001.html>