First read the generic instructions for all the software installations you will need:
Setting up a basic Expo laptop
Setting up a machine for Expo data maintenance
Setting up a Windows machine for Expo data maintenance
WSL now installs as WSL2 by default, but older machines (mostly laptops) may not have the Hyper-V Virtualization hardware and may have to run WSL1. This is fine: the behaviour is nearly identical so far as an expo laptop is concerned, where you just want to use rsync and scp. An old 2011-era PC has been doing troggle development happily using WSL1.
For some laptops though, WSL1 does not install properly and you have to use WSL2. The symptom is two error messages when you run dmesg in the Linux bash terminal window. However, if all you want to use it for is rsync, this may still be fine.
On some Windows 10 laptops WSL1 fails to install properly and you have to use WSL2.
When running a full troggle development laptop (see separate troggle documentation) you will want to use python venv. This barfs untidily if you have the code on NTFS, e.g. if mounted on /mnt/c/. You almost certainly have to move all your code to the internal network share e.g. \\wsl$\Ubuntu-20.04\home\expo\troggle\ which is how it looks when you are browing from Windows. (No, don't try to be cute and keep it on /mnt/c/ and just put a soft link in /home/expo/. That doesn't work either.) This means that the code is actually living on a Linux ext4 filesystem hidden away on your disc where you can only see it using the 'network' method \\wsl$\Ubuntu-20.04\home\expo\troggle\. This means that file access is somewhat faster too but you probably won't notice.
rsync doesn't work with NTFS partitions the way that WSL1 does. See Read WSL & Visual Studio Code and go back and read the bits about VS Code
running remotely in the ※Windows data maintenance laptop page.
WSL using files on NTFS unfortunately introduces a wonderful new problem of file permissions. Every file on the Windows filesystem NTFS has a set of
permissions managed by the filesystem. Every NTFS file that WSL knows about (if mounted with -o metadata) acquires a completely parallel set of file
permissions that are fundamentally different things and are never in sync in any sense. All sorts of fun results. The alternative is to store all your data
in the \\wsl$\ ext4 filesystem (WSL2 only, not WSL1).
If you are disturbed by the instructions to produce an entirely different key for WSL to use when your PC already has a perfectly good PuTTy key installed on the server, then you are right. It is inelegant. But it works, the instructions are shorter and there are fewer things that go wrong. If you are terribly offended by that then you can set your PC up to use one key shared between WSL and normal-Windows as described in this October 2019 article. (Don't set up a password on the key because then you don't need to install keychain.) But beware, this sort of thing goes out of date quite rapidly.
Links to useful articles to help you work this out for yourself:
When things go wrong when trying to sort this out, you may find these pages useful. I did.
rsync - failed to set permission - operation not permitted
file-system-improvements-to-the-windows-subsystem-for-linux/
id-rsa-pub-file-ssh-error-invalid-format
key-load-public-invalid-format
ssh-error-loading-key-id-rsa-invalid-format
chmod-chown-wsl-improvements
mount-usb-drives-windows-subsystem-for-linux
ssh command line
Now return to ※the Windows data maintenance laptop page to configure all the rest of the software you need.⁂
WSL1 gotchas and tips
Installing and Configuring the rest of the software you need on Windows