Windows development challenges

At present, I think all of our contributors are working on Linux/MacOS, and while we test fairly exhaustively on Windows in CI, it’s not much fun to develop locally.

Some things I’ve encountered trying to test #245:

• binder/postBuild is written in bash
  • we could write it in python
  • as more things seem error prone (anything involving node), doit (a la #183) would probably be helpful
• prettier doesn’t work
  • we can change the globs to be cmd-friendly
• nblint doesn’t work
  • just needs some path/encoding stuff for node, pathlib

will update as i find more…

[bollwyvl]

Thanks for the info, folks! We’re aware of most of the options presented, I was really just documenting how badly I’ve set up the content of this repo for windows devs while trying to run down some issues… anybody is welcome to PR fixes!

As to bash-like-things on windows:

yeah, my cross-platform inclination is to reach for python over trying to introduce another bash to windows. I’ve been bitten by trying to support cygwin-wsl-posh-cmdr-powershell-gitbash. luckily the bash language server we test doesn’t need bash!

As to pip-vs-conda:

We maintain, and test, a pip-based setup approach for unit tests… which will get a developer up to being able to test one language server and no UI. We end up using whatever nodejs happens to be lying around on CI. This approach carries the dangling caveat of, “go figure node, and r out yourself.” In the readthedocs pipeline, we have to bring our own node (theirs is EOL, last i checked), but then use pip for everything else.

Due to the nature of supporting LSP, we’re pulling in at least three languages already, on three platforms, and would love to test more (Julia, elixir, latex, etc.) so yeah, “just pip” is kind of a non-starter. Heck, we do use pip to install stuff that I haven’t had the time to PR to conda-forge. But anyhow: what I’m not going to do with my free time is build, document, and maintain rube-goldbergian contraptions of brew-choco-apt-pacman-yum-dnf-snap-flatpak-emerge on two proprietary operating systems and a multiverse of free distros, that at the end of the day can’t be distributed as a functioning component short of containers or heavyweight VM. Theoretically PRs welcome, I guess…

[flutefreak7]

I’ve had challenges with the conda ecosystem several times over the years and have been happily using a pip-based setup for the last two years specifically because there are so many more people using pip and pypi than are using conda and I’ve found it to be much better supported for a broad range of tasks. My issues were with conda and conda-forge not having libraries I needed, pip not mixing well with conda installations causing completely broken installations, and with issues like PyCharm and pyinstaller not knowing where conda was putting things half the time.

In my experience a library that wants to support Windows should support pip-based installations first, unless you have a ton of non-python dependencies for which conda packages make more sense than wheels and/or you exist as part of a tight web of tools that are already only on conda-forge (I experienced this with FreeCAD for example).

All that said, if you need MSYS or git-bash or whatever (the same as what conda install posix is installing) as a dependency of jupyterlab-lsp, then make it a dependency and document it. It’s not unreasonable for a Windows developer to have git-bash installed as part of Git for Windows.