How understanding software versions can help you get unstuck

Today I thought I would document how I got past a problem related to software versions that I encountered whilst using a tool on Windows Subsystem for Linux.

tl;dr

In a more general sense, I remember when I started working with software tools 4 years ago, and it never occurred to me that the problems we face working with software on a daily basis can often be solved by:

• Downgrading or upgrading the version we are using
• using workarounds provided by other individuals
• raising an issue ourselves with the maintainer, Stackoverflow, or asking elsewhere on the internet

For example for the Rust ecosystem's package manager "Cargo" we can see the different versions available here.

The Problem

OK, so I recently ran into an issue publishing a crate from Windows System for Linux (WSL) for the first time.

It seems the cargo publish command does not work when the repository is based in the mounted Windows directory.

So the directories involved in this process look like.

|-- ~/
|-- /mnt/c/Users/david/Documents/Github/nixy                                           

You can see that my project is in the Windows user's documents folder.

Has someone else solved the problem?

To avoid reinventing the wheel, also I didn't immediately think of where to go, I Googled the error message I received when I tried to run cargo publish.

There is an issue where this is being tracked here and more technical detail about why this actually happens here.

Trying one of the workarounds

Based on a comment in #8439 I took the following steps to fix my problem for the day.

I checked whether the directory in the workaround existed.

wsl@DESKTOP-DCRMGFD:/mnt/c/Users/david/Documents/GitHub/nixy$ cd ~

Then I returned to the previous directory I was in.

wsl@DESKTOP-DCRMGFD:~$ cd -

Then I went to the parent directory of the project.

wsl@DESKTOP-DCRMGFD:/mnt/c/Users/david/Documents/Github/nixy$ cd ..

Then I recursively copied the project to the WSL home folder.

$ wsl@DESKTOP-DCRMGFD:/mnt/c/Users/david/Documents/Github/$ cp -R ./nixy ~

Then I navigated to the second project location in the WSL home folder and ran the publish command again.

wsl@DESKTOP-DCRMGFD:/mnt/c/Users/david/Documents/Github$ cd ~
wsl@DESKTOP-DCRMGFD:~$ ls
nixy
wsl@DESKTOP-DCRMGFD:~$ cd nixy
wsl@DESKTOP-DCRMGFD:~/nixy$ ls
Cargo.toml  LICENSE  README.md  src  target  tests
wsl@DESKTOP-DCRMGFD:~/nixy$ cargo publish
    Updating crates.io index
   Packaging nixy v0.1.0 (/home/wsl/nixy)
   Verifying nixy v0.1.0 (/home/wsl/nixy)
   Compiling nixy v0.1.0 (/home/wsl/nixy/target/package/nixy-0.1.0)
    Finished dev [unoptimized + debuginfo] target(s) in 2.53s
   Uploading nixy v0.1.0 (/home/wsl/nixy)
wsl@DESKTOP-DCRMGFD:~/nixy$ 

Do I have to use the workaround?

No! You can now upgrade to the latest version of Cargo and this should work across the mounted /mnt/c/ directory.

I did this by checking my installed Cargo version, which told me I'm on a version from 2020-10-14.

wsl@DESKTOP-DCRMGFD:~/nixy$ cargo --version
cargo 1.48.0 (65cbdd2dc 2020-10-14)

I can see on #8950 that the fix was merged to master on 7th December.

So I update the rust toolchain, which in turn updates the Cargo publish command.

wsl@DESKTOP-DCRMGFD:/mnt/c/Users/david/Documents/Github$ rustup update

This gives me the following Rust version which is actually just before the fix was merged, might need to switch to the nightly channel to access 1.50 and any bug fixes associated with it.

wsl@DESKTOP-DCRMGFD:/mnt/c/Users/david/Documents/Github$ cargo --version
cargo 1.49.0 (d00d64df9 2020-12-05)

Wrapping up

Thanks to those awesome people who contribute to the Rust ecosystem, mostly in their free time, to add fixes like the one I benefitted from in this post!

I'll try to remember to update this post once I publish a new version of my Crate to test the problem.

Feel free to join in the discussion below, until next time 👋.