Regarding Windows Support

[mitsuhiko]

Rye right now is an experiment, and in many ways a demonstration of what package and project management in Python could be. For me this means I also want to have that experiment demonstrate that a good Windows experience can be found. However because I'm not using Windows all that much, I am trying to understand what an appropriate Windows experience would be like.

As with macOS and Linux I want to emulate the rustup/cargo world as close as possible, but there are some differences in practice that the underlying operating systems put in place. In particular the windows Python world has some significant differences to the POSIX pythons.

One quite significant question about it is if a tool like rye would be able to rely on symlinks. If it can, a lot of opportunities open up to closer align the concepts to Linux and macOS. However symlinks effectively require Windows 10 as the lower Python bound and that might be quite aggressive.

[cnpryer]

Is there a way to get nix::unistd::execv kind of process replacement but on Windows? Do you have to do this by interrupting the current one and spawning a new one?

Used https://github.com/mitsuhiko/rye/blob/aa559499453a6de2905a40c6ef736e50f6421fa1/rye/src/cli/shim.rs#L113

And https://github.com/mitsuhiko/rye/blob/aa559499453a6de2905a40c6ef736e50f6421fa1/rye/src/cli/run.rs#L90

[mitsuhiko]

I would not even try to do process replacement on windows. I'm not sure if this is actually necessary. My strategy there would just be to spawn the target process directly from the shim, install a dummy SetConsoleCtrlHandler and just propagate the subprocess's exit code when it finally returns.

[T-256]

if symlink is the only blocker for windows support, I suggest implement it to support win10+ at first, then bring support for older windows versions by few tricks, like junction or direct use of interpreter if possible.

[mitsuhiko]

The latest version now does something on Windows, but it's most likely full of bugs and limitations still.

[T-256]

Thats true symlinks still have few limitations on different situations.
But I think currently the bugs are only from path resolving & file and folder different names. I suggest to refactor project and moving each part need to resolve paths under few functions. more like get_venv_python_bin.

[cnpryer]

I have a windows machine I could use to tackle some of these if they bubble up into gh issues. My work machine is windows actually, so I'll try to migrate some of our projects to use rye to dogfood it. I'll aim to set this up next week 🤞.

[mitsuhiko]

That would be awesome. I made some improvements so it should work without symlink permissions now.