Tools, Not Metallurgy

Imagine if every time you wanted to acquire a wrench, you had to use a forge to get it. But not just any forge - you must use the exact type of forge that the wrench designer preferred, plus all of the exact tools that they preferred when inventing this wrench.

If you have a 10-lb hammer but the wrenchsmith preferred a 9.5-lb hammer, then your 10-lb hammer will not suffice to forge this wrench. And if the 9.5-lb hammer was not made in the exact type of forge that you already have, then you will also need to acquire a forge that produces 9.5-lb hammers plus all the tools needed to run that forge.

Sounds reasonable, right?

Let me show you something:

pip install ansible

I would like a tool to manage my server, please. The steps to acquire this tool are:

• Have the exact forge (Python v3.11) that the toolmaker wants.
• Acquire / create dozens of tools (pip packages) with this forge that are not the tool that I want but precursors to it.
• If any of those precursor tools require other forges (eg, gcc), then acquire and create those as well.
• Repeat until I have dozens of tools that I don’t want, plus all the toolmaking ability in the world, as a side-effect of acquiring the one tool that I actually want.

Don’t get me wrong, interpreted languages are neat. For the toolmakers. And who doesn’t love to make tools all day long? But if instead you fancy yourself a user of tools today rather than a toolmaker, you might find that your use case is not the one that gets optimized for.

This all sounds like bellyaching. After all, you’re always free to use a different toolchain.

However, I recently realized how many quickstarts begin with npm or pip or, god forbid, bundle, and I think that this is a problem, especially for junior engineers. Your new users are not your development peers – they don’t want or need the ability to modify the tool when it’s the first time they’re using it. And polluting the system-wide set of installed packages on the machine of a young engineer is a pretty harsh way to teach them about venv (et al).

Rootless containers are a thing now, as are easy-to-use compiled languages with a ton of library support. We can even compile Python to a single executable fairly easily. So why are we still distributing software via forge? And why do the documented introductory approaches still always default to building everything yourself? Why are we encouraging the users with the least experience to go make a mess of their system that they most likely won’t know how to clean up?

I don’t need the ability to reboot civilization, I just need something to run apt for me.

I’m picking on Ansible here only because it was a recent need. But the defaults matter, and this madness is everywhere. To quote Dr. Horrible, “The status is not quo!”

It’s amusing to me how rooted people are to their own personal contexts. Even when undertaking the act of building a tool for other people and writing documentation to teach them how to use it, most toolmakers cannot escape the context of being a toolmaker.