It's nor entirely cool, nor revolutionary, but I use this many times a day, so I thought that it could maybe fit in. I've built dew (
https://github.com/efrecon/dew). It's a glorified way of running a docker container as yourself with the current directory mapped as itself inside the container. Sometimes you will also need some access to the XDG directories.
I got tired of installations that would break others and of project requirements that would differ from others in tooling. So I use dew to run most of the CLI tools that I need and to build development environments that fit the (sub-)project at hand. When things go mad or disk space has become short, it is only a matter of cleaning the set of docker images to recover.
You don't need dew to do all this, aliases will do in most cases. They would all be mostly the same and you would have to remember how to solve problems for each tool at hand. So dew groups those under a few concepts that you can turn on and off for the specific tool/environment to run. It hides all those ugly CLI parameters behind configuration variables, and finds the set of necessary variables for a given tool/environment under a .env file automatically. dew is quick enough. In most cases there is little difference between running "dew yourfantastictool" compared to running yourfantastictool installed directly on the host.
The code has grown with time so I have used dew as an exercise in trying to write readable code and organise it, even though it's written in good old shell and has long passed the size of what should be written in shell...
Things that perhaps are a little cool with dew:
- It can rebase a barebone image on top of another one, so that you can use the tool from the barebone image and perhaps rebase on something that has coreutils or similar. This is remembered as a local image for next time.
- It can inject commands to be run before becoming "you" in the shell, so you can install more (as root inside the container) before switching to a gentle user. This is remembered as a local image for next time.
- It can use a local Dockerfile for complex scenarios. This can replace the two cases above.
- You can have access to docker from inside the container, and it downloads the latest version of the docker client for you (by default: this can be turned off).
- It can create files and directories, possibly with initial content for you before running the container. This is because -v xxx:xxx will always create a directory if xxx did not exist, and because some tools require a minimal configuration file to run.
- It has initial support for podman, but I still haven't given this as much love than the rest so your mileage may vary...