Weekly Journal 10 - asdf, pre-commit, gitlint

Synopsis

I have been working on better ways to manage multiple language environments and enforce team conventions. To that end, I have been experimenting with some new tools. First up is asdf, a tool for managing multiple versions of scripting language environments like Python and Node.js. To help with checking on team conventions at commit time, I am experimenting with a combination of pre-commit, for managing git hooks, and gitlint, which adds linting rules for commit messages.

asdf

asdf is a version management tool for a variety of languages and utilities. I am using it to install multiple versions of Python and Node.js for work and personal projects, but it also supports a number of popular utilities like awscli, direnv, jq, and many others. So far it has been working very well for my Python projects. I can have multiple versions of Python installed simultaneously, it works with virtual environments, and even allows access to Python tools I have installed with the system Python environment.

I was pleasantly surprised to discover I can create a Python virtual environment using a version managed by asdf. This allows me to install packages local to each project without causing dependency issues. I really like the fact asdf supports multiple languages and tools, so I do not have install and use a different tool for each language.

pre-commit

pre-commit is a tool for installing and managing git commit hooks. If you have ever wanted to trigger linter checks and run code formatting automatically when you commit, then this is something you should take a look at. It has plugins for many popular tools and is extensible so you can add new ones as needed. In the case of Python, it has support for flake8 and black, and for Javascript it has support for Prettier and about a thousands other utilities that I am not familiar with.

Gitlint

gitlint is a Python-based linter for git commit messages. There is a pre-commit plugin for it available, so it is easy to use with the other tools I have been looking at. The purpose of gitlint is to ensure commit messages are written in a consistent format and with consistent information. In my case, we have been looking at adopting Conventional Commits at work. Using gitlint would make sure we all remember to follow the conventions by causing the commit to fail. This is more useful for teams versus individual projects, but if you really like having consistent commit messages it can help.

What’s Next?

This week it looks like I will be focusing on AWS security. Depending on how far I get, I should have some notes to share on AWS Config and Security Hub next week.