Basic Windows port for install.sh, documentation updated for example usage.

[joeswagson]

Uses a PowerShell script with a custom implemented Write-Ansi function for support with terminals that don't recognize Ansi codes (seemingly everything I use).

[joeswagson]

Accidentally created a pr prematurely, I intend to port as much of the documented process as I can. This is currently just a windows installer script.

Edit: The script is still functional, but there hasn't been anything to ensure the tito module runs smoothly on Windows.

[profvjreddi]

Hey @joeswagson -- thank you so much for taking ownership and doing the port.

I just converted this PR into draft since you said it's not ready yet.

I've actually been changing the order of the modules. So just a heads up. It shouldn't matter for the script, but I wanted to let you know.

[profvjreddi]

Thanks for working on this @joeswagson! Windows support is definitely needed.

One concern we have: with separate install.sh and install.ps1 scripts, we now have two codebases to maintain. Any config changes (repo URL, branch, installation steps) would need updating in both places, and the logic could drift out of sync over time.

Do you think there is an approach that would let us maintain a single installer script that works across platforms? Or do you feel the two-script approach is the best path forward here?

Just wanted to raise this before we commit to maintaining both. Would love to hear your thoughts!

[rnjema]

Thanks @joeswagson for the effort. I concur with your concern @profvjreddi, while a Windows-native installer script really does help in the interim, it would really complicate any future work going forward.

It would thus really be convenient to target Unix environments. So where does that leave users of Windows like myself 🤔 ? Two options for unification worthy considering -

1. Git Bash : Given the fact the setup of tinytorch requires git installed, I would think using Git Bash is the more natural choice for Windows users to support the bootstrapping of the project (in this regard minor modifications on the installer script would have to be made especially to support setup of virtual env - for which I have been happy to hack my way around 😊
2. Windows Subsystem for Linux (WSL) : Using Debian-based WSL distros is also another fitting option that I have explored and currently works like a charm.

Just to mention , with the modified Bash script, I experimented with a mint Ubuntu 22.04 WSL image which works without hassle however I have had a few issues with an Ubuntu 24.04 image that uses uv for Python version and environment management but got it to work eventually. Find the proposed modification in this pull request #1105

[joeswagson]

Overall maintaining a project to have support for multiple operating systems is a difficult task. It is for its reasons though; typically the workflow is to have multiple setup processes that initialize a universal environment.

Python is a universal language, with multiple runtimes compiled for different systems. Most things, even the installer script itself, should be able to be made into a script. This script can check the operating system and control execution flow accordingly. This is a general benefit to interpreted languages, and as such most libraries that interact with the underlying operating system already have such checks in place to ensure consistency across platforms.

I'm personally not familiar enough with Git Bash to comment on any issues that could arise from how they emulate a bash terminal, so I'll just leave my concern of Git Bash potentially not supporting all the commands that are used in this project.

As for WSL, it is an amazing alternative for those who can run it. Issue with WSL is how close to the windows kernel it operates and as such the features required to make this work. I've had past troubles on my host machine as my BIOS frequently breaks with the boot configuration changes WSL applies.

These two also aren't, in my opinion, proper unification. This to me would be embedded support with the operating system in mind, rather than using workarounds to make it emulate or appear as the desired environment.

WSL is the best solution there is right now, I'm mostly trying to work towards a solution that provides native support without the need for a middleman.

[rnjema]

@joeswagson Your concern is indeed valid. So far unless there are any breaking changes to the current interation of the installer Bash script, Git Bash supports all the commands currently used.

On the flip side, implementing a Python script to handle a more platform-agnostic boostrapping of the project is also worthy exploring (which I suppose is what you are suggestively alluding to this in this case). Happy hacking ✊

[profvjreddi]

Thank you @joeswagson for developing the PowerShell installer! 🎉

We've decided to standardize on the Git Bash approach (which is now working well thanks to the community's help, but your contribution was valuable in exploring the Windows installation space.

You've been credited as a contributor to TinyTorch for your work on Windows support. We really appreciate you taking the time to help make TinyTorch accessible to Windows users!

If you'd like to continue contributing, we'd love help testing the Git Bash installer or improving the documentation further.
EOF
)