At the heart of dependency management, whether we're talking about programming languages or higher level platforms such as operating systems, is people. Dependency management is a social act of people sharing and using each others work.

With people at the center of it all we have to deal with things like:

1. Trust. Who trusts who and to what amount? How do we verify something came from a trusted source? What about people caring about different needs of trust?
2. Accidents. People aren't perfect. We screw up. How do we handle and work with imperfect people?
3. Disagreements. We are good at disagreeing. We end up putting a lot of work into trying to come together. Yet, even when we work together on specs or agree to use them there are cases where people break from them. How do we handle that?

Even before we get to any of this we need to acknowledge that people take on quite different roles in the system of dependency management. Those roles can be wildly different from each other. Sometimes we even need to talk about which role to prioritize over another when making design decision.

Yet, how often do we think of these roles and their differences? Let's take a look at them and see what we can find.

Continue Reading »

What do users need from their package dependency management? A lot has already been written on this including the output from a survey of Go developers, a specification for a dependency management tool by those who studied the issue and possible solutions, a series on vgo by Russ Cox, and even follow-up posts by Sam Boyer, one of the dep maintainers. With so many words already written, what more do people need to consider?

When Sam Boyer recently quoted Alistair Cockburn in his write-up on MVS failure modes I realized we aren't all thinking of people the same way. Dependency management tools are there to aid people. Who are these people and what do they need and want?

Continue Reading »

"Those who don't know history are doomed to repeat it." ― Edmund Burke

There are many variations on this saying but the essential element is that it's important, and I would argue useful, to know the history of something. It can provide depth, understanding, and insight.

At the moment there are many debates going on about package management in Go. There are questions being asked, such as how should it work or whose ideas should we follow?

To give context to these ideas it's worth looking at the history of dependency management in Go. It's a story of people, discovery, differences, disconnects, and even a little drama.

Continue Reading »

In my previous post I shared an example of how dependencies could break under vgo when semantic versioning rules are broken. That post talked about people, trust, and tooling in relation to MVS. One of the pieces of feedback I got was that the example could be more clear. So, here goes...

Continue Reading »

Note, a second post with some additional detail is available in a post titled "Go vgo: A Broken Dependency Tree".

In Sam Boyer's introduction to his analysis of vgo he touched on a number of practical, day in and day out, issues that can arise from using MVS. MVS, an acronym for Minimal Version Selection, is a new algorithm for solving a dependency tree. You can read more about it in Russ Cox's series.

MVS is a new algorithm not found in other programming language package managers making it, in my opinion, something worth analysis and discussion. We should understand what we're getting ourselves into, warts and all, because it's different than we're used to.

In Sam's analysis he noted a case that goes like this:

“Our project depends on [email protected] right now, but it doesn’t work with [email protected] or newer. We want to be good citizens and adapt, but we just don’t have the bandwidth right now.”

I wanted to share a real world example where this happened.

Continue Reading »