Omakub on WSL

[andreimaxim]

I've been running a bastardized version of Omakub for my Windows + WSL setup and I figured I should share my findings here because it would be really awesome to have a nice development environment when running Windows.

WSL2 defaults to Ubuntu 22.04 LTS

If you follow the official WSL installation guide, you'll end up running wsl --install which automatically installs the default Ubuntu distribution. Right now, this means that you'll be running in WSL Ubuntu 22.04.

Since Omakub is targeting Ubuntu 24.04, I think the solution here would be to specify wsl --install -d Ubuntu-24.04 somewhere in the docs.

Windows injects values in the $PATH

Omakub sets the complete $PATH. However, WSL sets up some extra paths automatically so you can access Windows files like ssh.exe (useful when signing commits via 1Password) or powershell.exe.

A simple solution here would be to set the path like this:

export PATH="$PATH:./bin:$HOME/.local/bin:..."

GUI apps work better as native Windows apps

I've decided to skip installing any of the GUI apps, since they work much better if you install them in Windows. Especially WhatsApp or Hey work much better in Windows since they aren't PWAs installed via Chrome.

I think some apps might be installable via scripts, but I'm not sure if it's worth it, since some are available in MS Store, some are downloads from the application's website and almost all of them have some sort of wizard you need to go through.

A side-effect is that theming won't work for GUI apps.

Neovim needs win32yank in order to use the system clipboard

In order for Neovim to have access to the contents of the Windows clipboard for copy & pasting, the win32yank package needs to be installed in Windows:

winget install win32yank

This also needs to be in the $PATH, see the previous comment.

Alacritty

Alacritty for Windows stores its configuration files in %APPDATA%/alacritty. %APPDATA% is a Windows-specific environment variable, but we can resolve it from WSL:

wslpath -u "$(powershell.exe '$env:APPDATA' | tr -d '\r')"

I was able to get a very similar setup using the following alacritty.toml configuration file:

import = [ 
    "~/AppData/Roaming/alacritty/omakub/theme.toml", 
    "~/AppData/Roaming/alacritty/omakub/font.toml", 
    "~/AppData/Roaming/alacritty/omakub/alacritty.toml"
]

[shell]
program = "C:\\Windows\\System32\\wsl.exe ~ -d Ubuntu-24.04"
args = ["zellij"]

Unfortunately, Alacritty seems to be using the default ConPTY on Windows, which has some bugs. Also, selecting some blank text in a Zellij pane (by accident) I get the following error which I haven't been able to fix so far:

Unable to store text in clipboard: The parameter is incorrect. (os error 87)

Since the fix for the Alacritty bug was to download WezTerm and use its version of ConPTY, I've used WezTerm as the default terminal the last couple of days and it seems just as smooth.

Detecting if Omakub is running in a WSL installation

Unfortunately, there isn't a canonical way to detect if the script is running within WSL or a regular Linux distribution.

I found two ways which should be good enough for most scenarios:

• verify if /proc/sys/kernel/osrelease output contains the word "microsoft" (this is how Lazygit detects WSL)
• verify if /proc/sys/fs/binfmt_misc/WSLInterop exists (this is how Snap detects WSL)

The big question now is if there's enough interest in having a Omakub for WSL and what would be the best way to handle things like different Alacritty config paths.

Thanks!

[csfh]

My 2 cents in a super condensed version:

Omakub is Omakase for Ubuntu.

I think what you are looking for is Omakase for WSL, and I'm not sure it benefits anyone if we try to jam it all in one package.

Nothing stopping you or anyone else from adopting the philosophy and applying it to WSL.

[andreimaxim]

@csfh if by "jam it all in one package" you mean running Powershell scripts, I do agree with you and I'm not trying to push the idea of expanding Omakub to also setup Windows machines. However, I think there are a couple of tweaks that Omakub could do in order to be friendlier to other kinds of setups, like expanding the PATH environment variable (instead of setting it), or having a "CLI-only" mode.

For the PATH issue I have already created a pull request (see #143) and this would allow an omakub-on-wsl package to checkout Omakub, run specific installers and then run a couple of Powershell scripts to copy the theme settings (for example).

[nickchomey]

This idea has already been rejected quite resoundingly. #72

[andreimaxim]

@nickchomey thank you, I only searched issues, not PRs.

I'll close this issue.