Windows python support should be made easier #23083
On my systems (as many are), I have both Python 2 and 3 installed with 3 being the default.
I personally symlink python 2.x to python2 and python2.7 on the PATH, but the Windows python versions provide its own solution to this:
Even manually running mach via python 2.7 runs into quite a few blockers, including the
In the case of
For whatever reason mach is still using Python 2, it should better support the fact that mach is already being run from a python interpreter and shouldn't need to try to make guesses on what the user's path/environment is and override the execution.
I nearly gave up on Servo because of the above problems because it wasn't clear what was going wrong, especially with the
I can certainly look into it soon. Currently it doesn't get through all of the dependencies for me because
I have some other ideas on how to (possibly) make Windows support easier (that I could presumably also work on), but that depends on some other infrastructure updates anyway.
How opposed would servo be on optionally seeing (via cmake) if vcpkg is installed and working on Windows before dragging in prebuilt binaries for end users? Or would that add too much non-determinism for the build process?
vcpkg lets Windows people add and manage compiled packages for other things to include in their build process. Right now, I think the main thing missing from vcpkg is gstreamer, which I can always try to get included. I think the downside with vcpkg is that there's no standard path on which it'd be installed or detectable.
vcpkg represents a development-minded package manager from Microsoft on that builds many things from source. It's pretty easy to use and extensible. It makes the most sense on Windows, at least if I can help them make sure they're discoverable from cmake. Since it's from Microsoft and open source, it's about as official as it gets for the platform.
It wouldn't necessarily make building easier in all cases, but would make it easier to keep things consistent. If someone's set up a development environment on their machine, presumably it'd be useful to ensure that the same MSVC version is used for all C, C++, and Rust bits and everything is ABI and linker compatible.
Of course, none of it applies (much) to MSYS2 or other things that are sufficiently UNIX-y.
I'd noticed servo downloading binaries for things like OpenSSL, which vcpkg can provide. Just as an optional thing to be able to pull library and header availability from would be nice. If I'm compiling things with cargo with the MSVC ABI, I'm already using cl.exe under the hood and it can be a good idea to make as much as possible compiled in the same fashion.
As I said, I think the only major piece missing that servo uses is gstreamer, but I can always file pull requests for that too.
I just realized as for vcpkg, there's a vcpkg crate which entirely simplifies things, and one of servo's dependencies already uses.
I'll definitely try to get gstreamer on there regardless as it could be useful.
As a sidenote, Rust infrastructure seems to be a lot more responsive than anything node-related. That's very reassuring to someone who's been run ragged trying to get bugs fixed elsewhere for ages.