Comment by nbadg | Hacker News Reader

Comment by nbadg | Hacker News Reader

Parent Full thread

For a brief minute I was hoping that this would be a built-in solution for mirroring host files to the linux VM, but alas...

I think development on windows has come a long, long way over the years, but I still feel like these days you're all but stuck going all-in on WSL -- meaning no more GUIs -- or keeping the GUIs but losing WSL. For example: if I want to use sourcetree for git on the host, but autoreload processes within docker when I change code, I'm basically out of luck: sourcetree can't deal with files on the linux filesystem (or at least, not on my setup, though that could be more than just an issue with sourcetree), so I have to store the files on the host. But things like inotify can't cross the filesystem boundary, so now autoreloading works. Which is why the advice is always just to keep all of your code within the WSL filesystem, but now the GUIs don't work. (I mean, I think in theory you can get GUIs from inside WSL, but I have absolutely no interest setting that up -- now it's like a Matryoshka doll of virtualization. Plus, some of the programs I want to use don't ship a linux version, so it's a moot point).

My workaround is annoying but effective, as long as you have a good enough system for it: I run a watcher process on the host and an rsync server within a dedicated docker container, and it syncs my code for me into a named docker volume. I guess this has the added benefit of allowing me to have my own filter files for whether or not things get copied over (I have multiple git repos, and I'd like each of them to obey their gitignores when copying), but... it's definitely pretty rough around the edges.

But still: any improvements are good!

This is probably a dumb comment, but have you looked into using WSLg? I.e. also run the GUI inside WSL? The integration between Win and WSLg is pretty seamless!

Not dumb at all; WSLg would actually work for linux applications, and in theory seems relatively painless, though I've never actually tried it. I think the guides I was looking at were pre-WSLg, where it was... a mess.

But it's kinda moot, because not all of the applications even have a linux version. Sourcetree is a great example: it's only available on windows and mac.

To complicate things further, because I move frequently between my laptop and my desktop, I have all of my source code in dropbox (including git, and yes, it's a shitshow, though I would like to change the way I have this set up because dropbox has a nasty habit of temporarily breaking git). And to complicate things _even further_, my old laptop is dying, and I'm replacing it with a macbook (and throwing ubuntu on the old one), so I'll have windows 10, mac, and linux all at the same time.

For the most part I make it work, but there are definitely days when I just want to throw them all out the window.

Both intellij/pycharm/… and vscode work with WSL these days. Dev tools have to adapt or die, more people seem to use WSL every day. Where I’m now, one of the blockers is the VPN/network issues mentioned here, so I imagine even more devs moving after that is sorted out

Don't get me wrong -- I'm not complaining! Like I said, improvements are just that: an improvement. And my priorities aren't the same as WSL2 priorities, that's clear too.

But I don't think it's reasonable to expect that all of my tooling work with WSL2. A decent chunk of my tooling isn't even developer-centric -- why would the tools I use for asset creation support WSL2? Should Adobe? Should Inkscape? What about the docker sync that I use for static assets, or for source code when I need to move between laptop and desktop and don't want to make a temporary commit or patch with git? Windows app development is already messy enough, are we going to require that everyone making a windows app jump through yet another hurdle, on the off-chance that the small percentage of windows users who happen to be devs can get it to work with docker containers? That doesn't seem reasonable to me.

There are plenty of people like me that choose to develop on windows (and aren't forced by a company to do so), precisely because they want to be able to use windows as they normally would, but also, yknow, develop code. All I'm saying is, having a native way to mirror a filesystem while providing the expected semantics on both sides of the share seems like an important feature for these kinds of workflows.

I see your point, but only partially. Why can’t you write code on windows today? I can, for some/most projects. Why do you then want WSL?

Whether or not you can develop the code directly on a windows host is highly dependent on what kind of code you're writing, and what environment it's being deployed to. It's the recommended way to do virtualization these days on Windows, and if you develop using docker, you have to use WSL. Even in cross-platform interpreted languages like python, if you have third-party deps, not all of them are available on windows, nor do they always work there. Basically, if you're deploying to a linux server but developing on the windows host machine, it's not a question of "if", but "when" you'll run into a problem, etc etc etc. And this is just the "easy" case, where everything is theoretically cross-platform; when you start getting into things that involve proprietary compiler toolchains or specific hardware targets, you don't always have a choice what platform you work on at all.

Put more directly: I don't think any of my previous employers would have had a problem with me developing on a windows machine, as long as I was running the code in a virtualized environment that matched production. But it wouldn't have been acceptable at any of them to run the code directly on the host.

Reply on news.ycombinator.com