thought-machine
Windows Support
I've not actually looked into what would be necessary to run please under Windows yet. However, I don't think I've ever seen sh being mentioned. This package is used internally by Task, providing its Windows compatibility layer.
I suspect that's not the only thing keeping please from running under Windows (probably some cgo plumbing, too) but maybe this would help with a more universal shell API surface across platforms.
I had a go at getting Please to work on windows but never quite got it to completely work: https://github.com/thought-machine/please/pull/1280
I realised pretty quickly that windows is different enough that we wouldn't be able to support it ourselves. It would increase the surface area quite drastically, and as we don't use windows internally, we can't dog-feed it properly. We're a small team, trying to support it would probably stretch us too far.
The way I see this happening is with a champion that was willing to take the plunge with us. I'd be happy to put in the effort to essentially get Please working on windows, but I don't think we'd provide a binary release. Somebody would likely then have to build out an ecosystem of build rules that work on the windows toolchain.
Tools like cygwin to provide a more unix like environment, and sh to help translate might help, but ultimately we'd probably want a set of c/c++ and go rules that use the windows compiler toolchain. The current set of build rules are very much unix oriented. We're in the process of moving the rules out into plugins, which should make it much easier to build a parallel set of windows build rules.
I had a go at getting Please to work on windows but never quite got it to completely work: #1280
I realised pretty quickly that windows is different enough that we wouldn't be able to support it ourselves. It would increase the surface area quite drastically, and as we don't use windows internally, we can't dog-feed it properly. We're a small team, trying to support it would probably stretch us too far.
The way I see this happening is with a champion that was willing to take the plunge with us. I'd be happy to put in the effort to essentially get Please working on windows, but I don't think we'd provide a binary release. Somebody would likely then have to build out an ecosystem of build rules that work on the windows toolchain.
Tools like cygwin to provide a more unix like environment, and sh to help translate might help, but ultimately we'd probably want a set of c/c++ and go rules that use the windows compiler toolchain. The current set of build rules are very much unix oriented. We're in the process of moving the rules out into plugins, which should make it much easier to build a parallel set of windows build rules.
I recently started work at a new company that is still vastly dependent on Microsoft infrastructure (even their npm scripts do some Windows specific voodoo) and I'm also in the process of porting some of my own software to Windows.
I could potentially be that "champion".
I see this as two somewhat separate questions - what does plz itself need in order to run, and what do the various build rules expect (as you say the current set are very Unixy, but they are also easier to experiment on in isolation). Although maybe there is crossover at the point where the Go rules are needed to build plz itself.
We can set up a Windows job on CircleCI so once it's working we should be fairly confident that it keeps doing so. (It costs a bit more to run another platform but it's not a big deal).
I could potentially be that "champion".
That would be amazing. It could be a fair bit of work, but I don't think it's impossibly hard by any stretch.
We don't need to build Please with the go rules to begin with. A plan forward might be:
- We work together to get Please to compile for Windows. We have CI to verify this, but windows remains an unsupported platform. We don't provide any binaries, for example. To begin with, these tests will probably have to remain pretty basic, i.e. just compiling Please, as we don't have any build rules.
- You might then begin work on Please plugins for c/c++ or Go. They might build and run Please with Go until the Go rules are complete, but at least we can get somewhere with this.
- Once there's a release of these plugins, we can add some e2e tests to our CI, that pull the plugin and run a subset of tests similar to the Python tests here.
- The go plugin reaches maturity and we're able to bootstrap, build, and test Please on Windows.
- Time goes on and support matures, we add windows to the release.
If you're interested in this, I suggest you take my PR above and try and get it to compile. I'm reasonably active on Gitter so might be able to help out, though I'm about to go on holiday so can't get that stuck in this month I'm afraid.
Hey! I've resurrected my old branch and merged master in:
https://github.com/Tatskaari/please/pull/1
I can build a basic genrule that calls out to echo to create a file. You can test it out with the following:
$ go build src/please.go && cd test/windows && ../../please.exe build
~We have to disable the cache dir as it doesn't know how to handle parsing the windows path in $HOME yet~
Migrated from path to path/filepath and that seems to have fixed the issue :D
When I get back, I'll try and break this up into smaller, more polished PRs that can land. Perhaps you can start playing around with this if you're keen and help identify some more issues?
Hey! I've resurrected my old branch and merged master in:
I can build a basic genrule that calls out to
echoto create a file. You can test it out with the following:$ go build src/please.go && cd test/windows && ../../please.exe build~We have to disable the cache dir as it doesn't know how to handle parsing the windows path in
$HOMEyet~Migrated from
pathtopath/filepathand that seems to have fixed the issue :DWhen I get back, I'll try and break this up into smaller, more polished PRs that can land. Perhaps you can start playing around with this if you're keen and help identify some more issues?
Awesome! Won't have much time until next month but I'll look into it ASAP.
Yea. path/filepath is preferable in this instance. Glad it worked. Was afraid I would've to undust an old home path library I wrote at my previous employer and never open sourced.
@markusbkk is there any development on this. I was hoping at some point we would be able to use it on windows.
@markusbkk is there any development on this. I was hoping at some point we would be able to use it on windows.
Sorry but no. I switched employers again and my current employer is entirely *nix (GNU/Linux and macOS) based so I don't really get the chance to work on this anymore.
Thanks for your response. I appreciate that. What was the main challange for getting it to work? If I would pick it up somehow would it be a major challenge?
Thanks for your response. I appreciate that. What was the main challange for getting it to work? If I would pick it up somehow would it be a major challenge?
The known issues are mostly around dealing with platform stuff like filepaths. I believe we got to the point where Please compield for windows, but none of the build rules worked as they assume a unix filesystem, and all the env variables like $PATH were using the wrong separator. This is not a small change but the known issues aren't that technical in nature either.
I can't promise any development right now but I will look into building it and testing what works. We are working in a big monorepo with scala, nodejs and also dotnet projects that can only be build on a Windows machine. Some part are able to work on dotnet sdk builds. But I'm hoping to get myself a bit more familiar with the codebase of please to understand the open issues.
I didn't forget to check this but Windows on Mac M1 is giving me some issues. But I will give it another go in the coming weeks.