Python is the New bash

bash (or at least Bourne shell sh) is ubiquitous in the Linux and BSD world. Replacing it with Python will not be easy, painless, or quick. But the plethora of base tools written in Python for Linux distributions testifies to the mindshare Python has gained. I don't expect the likes of FreeBSD, for example, to bring Python into base anytime soon. But we as users can certainly replace our code written in shell with Python.

There was a time when bootstrapping the right version of Python on an operating system was an involved task. It is not as big a deal anymore. We can control what gets installed in the base OS image with tools like Packer. Even Terraform gives us remote-exec to install Python when using an image we don't control.

Once we have a non-system-installed Python in the target OS, we can use tools like pipenv to customize multiple environments for our applications. In cases where two tools have conflicting dependencies and cannot be installed together, either install them in different virtual environments or create and use very tiny Docker containers. Or if we have access to a modern Linux distro that supports snaps, we can install Python in a snap.

The biggest strength of Python is its developer community. I have not had to write code for many complicated things because someone else already wrote it with a permissive license. Why not leverage this strength?

Use the power of the Python ecosystem to make our job easier. Granted, it seems overkill to install Python, lots of dependency packages, and maybe Docker to replace good old bash but look at all the additional power we get and how very complex problems with inelegant solutions in bash can be done in a more elegant and maintainable way with all these tools.

Python has all the source code we need, just like bash, installed on our system, unlike say a Go or C binary. That gives more control to the user to understand, modify, and fix it when needed. We retain control the same way but have even more libraries to leverage.

I still write tiny shell scripts or even make files to get some quick things done sooner. But I move that codebase to Python when I need to care about readability and error handling/recovery.

Shipping Python to people whose environments we don't or can't control is still not as easy as shipping a single static binary built with Go. The version of Python installed on someone else's computer is also a consideration. While there are numerous solutions to tackle these and other challenges, they are not always enough. Nevertheless, we can at least start to migrate to Python environments that we control.

bash will not go away and it shouldn't. Just like Assembly hasn't gone away with the rise of C or C hasn't gone away with the rise of Python. We need all these tools to thrive so we can get things done. Python is a better tool than bash for the future that consists of cloud native, IoT, machine learning, and other things we can't even imagine today. We should use the best tool available at that time.

Some day another tool will come along and if it solves the needs we have then, I will likely write a similar post how that tool is the new Python. Until then, you will find me camped firmly in Python's corner.