Support Windows PATH

[brettcannon]

Also requires getting compilation to work.

[messense]

It doesn't compile on Windows due to the use of nix crate.

[brettcannon]

Correct, no attempt has been made at Windows support yet.

[cnpryer]

Maybe I'm misunderstanding, but it seems like the nix dependency is only used for the py binary. The library could still implement support for PATH, right?

[brettcannon]

Maybe I'm misunderstanding, but it seems like the nix dependency is only used for the py binary. The library could still implement support for PATH, right?

There isn't really a separate library yet, but there are plans to create one. In that instance there shouldn't be an issue with Windows support. I do still hope to eventually make the binary work with Windows as well.

[cnpryer]

Cool! Are you open to PRs to help support Windows even if it's just library changes? I looked into options for the py changes, but I couldn't find anything low-hanging that'd replace the process for you instead of just spawning a second one.

Referring to #2 (comment) specifically.

[brettcannon]

Are you open to PRs to help support Windows even if it's just library changes?

Not at this moment as I would worry it wouldn't get tested appropriately until it is a separate crate. But once the separate crate exists I will definitely take a PR!

I couldn't find anything low-hanging that'd replace the process for you instead of just spawning a second one.

I honestly don't think such an option exists on Windows, so it will just require launching a second process. I haven't delved into that because if you look at https://github.com/python/cpython/blob/main/PC/launcher2.c you will notice it isn't a simple "launch another process" thing.

[cnpryer]

FWIW it looks like cargo tries to do this with a Ctrl-C signal
https://github.com/rust-lang/cargo/blob/4a3c588b1f0a8e2dc8dd8789dbf3b6a71b02ed49/crates/cargo-util/src/process_builder.rs#L259-L276

[jaraco]

It doesn't compile on Windows due to the use of nix crate.

Maybe "Compile and run on Windows" (or similar) should be a separate issue in this milestone? The current list of milestones implies that it's already compiling and running and there are some unmet features.

Not at this moment as I would worry it wouldn't get tested appropriately until it is a separate crate.

Perhaps this should also be a separate issue in the milestone?