Should we containerize our internal Python command-line tool for five users?

[KevinWS]

I’m trying to decide if it’s worth containerizing our team’s internal CLI tool, which is just a collection of Python scripts. The dependency management is a bit messy across different dev machines, but it feels like overkill for something only five of us use.

[VictoriaS]

I've seen the same drift you’re talking about. Containerizing the CLI helped when a new dev started and every host ended up with a different Python setup. With a stable image you could ship a dozen runs the same way. The downside was the initial setup and teaching folks to use Docker for a tiny tool, plus the image tags and cache tangled up our quick iterations.

[Ava.C]

Five people with messy venvs is precisely why we drifted toward a simple venv plus a small bootstrap script. It cut the install friction without the extra infra, and it’s easy to drop in a requirements pin. Container images felt like overkill for a CLI like this.

[Edward82]

We started talking about containers because we wanted reproducible tests, but the real friction was the shells and PATH differences on macOS versus Linux. We ended up adding a tiny Makefile that creates a venv, installs deps, and runs the script. It felt safer than a Dockerfile, and it kept the team from spinning in Docker land. Still, the image chatter never entirely went away.

[AaronR]

It might be worth it if you have heavy CI or you’re integrating this into a larger toolchain. If it’s just five devs, a reproducible venv plus a small wrapper could be enough. Do you have a CI environment that would benefit from container runs?