I guess one of the many reasons I never considered myself to be a Real Developer™ — just "a guy who writes code to automate things" — is my habits and preferences aren't what I observe to be the norm for Real Developers™.
- I fucking hate Apple products: I want my computing environment to be fully and wholly tailorable to my my tastes. That and Apple hardware's keyboards, mice and track-pads are trash and their WM sucks. Since I can't have a NeXTish (closest you get, nowadays, is GNUstep under WindowMaker; but back in the early 00s, used to be able to run a shell-replacement that gave you an OpenStep type of launcher) or 4Dwm (SGI) style window-manager, I'd much rather Windows' interface. While it's not my ideal, it's at least got the key-bindings I prefer. Plus, I can still easily get devices with a full US101-style keyboard (everyone's gone to "buttonless" track-pads, so I'm doomed on that front whenever I'm forced to change off). It's why I've been resisting my company's attempts to issue me a work laptop since they decided that Apple hardware was a great perk to attract new hires with …and subsequently implemented centralized device management (MDM) to meet compliance goals.
- Resultant of the immediately prior, I use
- A Dell laptop (and an HP before it)
- I run Windows 11 Pro (though, when I bought it in spring of 2020, it came with and was upgraded from Windows 10)
- I would run a Linux-based desktop, but, when I bought the current laptop, the options for laptops preloaded with Linux were quite limited (and I just didn't want to have to ass around with it). If I had the money and time, I'd try to run a hypervisor as my bare-metal operating system, then, as my default VM, have an RPM-based distro like Fedora, Alma or Rocky as its OS. Professionally, my customers are RPM-based, so, just like in my SGI and then Sun sysadmin days, I tried to minimize the cognitive-load of OS-switching by running equivalents on my personal systems.
- That said, my choice of Windows as my OS being a matter of convenience, I don't really use Windows as much more than a hosting environment.
- I use WSL2 for my "daily-driver" working-environment. My main WLS2 instance runs Oracle Enterprise Linux 9 (at the time, it was the only free EL-style instance available and I didn't want to go the Ubuntu route). I run an OpenSSH daemon inside it so I can use PuTTY to login to it.
- I use Hyper•V on the occasions where I need to run a full VM. Those occasions are fairly rare, thoug. Mostly, I used them when I need something that runs DBUS/systemd or needs to interact with something closer to "real" devices (e.g., when I'm having to prototype automation for services get pissed when there's no DBUS/systemd bits)
- I use PodMan, instead of Docker, inside my WSL2 or Hyper•V VMs.
- I run work-related tooling — be that browsers, tools like Teams/WebEx/etc. — either from my WSL instance or a full VM. I generally believe in keeping work stuff siloed off from my main OS
Recently, a new project popped up on my work RADAR. That's going to require using something other than either a WSL-encapsulated PodMan or a Hyper•V. Instead, for the early phases, I'll need to do at least some tasks in Docker Desktop (which, on Windows, is underpinned by Hyper•V).
I'm not really a GUI guy nor do I want to have to dick around with CMD.EXE or PowerShell to manage Docker. I much prefer to do everything from a BASH prompt and to use vi and other tools that I have two to three-and-a-half decades of finger-memory for.
On the plus side, Docker Desktop has native integration with WSL2. You just have to enable it:
On the minus side, if, like me, you've installed the podman-docker RPM into your environment, it makes interacting with DockerDesktop from your WSL2 CLI session a bit more of a bother to set up. It requires:
- Knowing where DockerDesktop has created its docker command within WSL
- Knowing where DockerDesktop has place its UNIX domain-socket into WSL
Once you know those — with Docker Desktop 4.77.0, those were "/mnt/wsl/docker-desktop/cli-tools/usr/bin" and "/mnt/wsl/docker-desktop-bind-mounts/OracleLinux_9/docker.sock", respectively — you need to tell your shell where to find them. For the former, you extend your "PATH" and for the latter you alter your "DOCKER_HOST" (shell envs).
That you have to know these things is a side effect of the podman-docker RPM wanting to manage many of the same things that the Docker Desktop insertions into the WSL 2 instance wants to take care of.
The other fun thing with the setup is that you have to keep re-defining "PATH" and "DOCKER_HOST" shell envs. That's not generally something I want to be bothered with or, more importantly, remembering. The "remembering" thing is why I write articles like this one.
Since my need for either PodMan or DockerDesktop is sporadic, I'd rather things like shell-envs be self-maintaining. A great way to do that is by using direnv. With that tool, all I have to do is drop my shell-envs into a ".envrc" file hosted in a specific directory(-tree) and, whenever I "cd" to that directory, I get the settings I desire. Podman is my default, so, for Docker Desktop, I only need to manage that in a top-level directory at the root of my "${HOME}". In my case, that directory is "DockerDesktop" (or "~/DockerDesktop" in BASH-ese). So, my "~/DockerDesktop/.envrc" ends up looking like:
PATH_add /mnt/wsl/docker-desktop/cli-tools/usr/bin PATH_add .bin export DOCKER_HOST=unix:///mnt/wsl/docker-desktop-bind-mounts/OracleLinux_9/docker.sock
That "PATH_add .bin" is the last bit of metaphorical "glue". It allows me to define a simple shell-wrapper at "~/DockerDesktop/.bin/docker-compose", allowing me to type "docker-compose" rather than "/mnt/wsl/docker-desktop/cli-tools/usr/local/lib/docker/cli-plugins/docker-compose" ...whenever I want to run "docker compose ..." to interact with Docker Desktop instead of PodMan. And, when I say "simple" I mean:
#!/bin/sh exec /mnt/wsl/docker-desktop/cli-tools/usr/local/lib/docker/cli-plugins/docker-compose "$@"
I assume there's probably even cleaner and/or less-effortful approaches, but this is what I was able to most-quickly cobble together, this morning
