So you think there are just going to be tons of little issues like this, so that using a shell-like language won’t make much sense at all?
Do you think it might be interesting or useful to see how annoying it is to write a cp -r that works on the Chromium sources on Windows in some of those shell languages, and maybe also Rakudo? That seems like something that might be fun for me to try once I have a little time.
I did in Perl5 (nix-windows discussed above was using Perl5 as stdenv.shell) and even that required a 3rd party module Win32::LongPath and patches. (Chef did something similar for Ruby: https://github.com/chef/chef/tree/main/lib/chef/win32). Rakudo’s only advantage is it has a bit better built-in support for Windows long paths and symlinks,
PowerShell Core (the open-source PowerShell implementation that gets all the cool new stuff, and has Linux and macOS ports) also always supports long file paths, even when the GPO setting on Windows for it is not enabled, and PowerShell includes built-ins for everything normally covered by coreutils.
It depends on .NET, so that sucks, and it may have other quirks. But the builtins supposedly will handle long paths, at least, and it’s probably better than depending on all of WSL.
I didn’t find any real documentation for this except this issue that notes that the old workaround (UNC paths starting with \\?\) is not needed on PowerShell Core as it is on the older distribution of PowerShell (‘Windows PowerShell’).
nushell is getting good, fast. The folks working on it seems serious, passionate and experienced in a way that I trust it’s going places. It’s cross-platform, it’s Rust, I think there might even have some potentially interesting places where we could do much better than passing everything as strings between nix<->shell.
The latest release has a lot of interesting changes. I thought this video was a nice snapshot that really gave me a good, rare vibe that I’ve learned to trust a bit: https://www.youtube.com/watch?v=-lWL7Nc-OX4
I still can’t seem to catch up with everything, but I want to prototype replacing some of my deployment scripts and internal nix->shell with nushell and see how it feels.
Yeah, at some point ill write some docs but first I’d like to “finish” this project, or at least get it into a better shape.
But all in all its nothing too special, tho there are a couple of implementation details that I am a fan of:
Phases are defined with an index that defines when to execute them, this allows users to add more phases for some individual steps and there is no need for preXyz/postXyz hooks since users can precisely decide when something should get exectued
Everything is a phase including dependency management. Time will tell if this approach will scale
Most attributes are past as JSON thus it is possible to pass complex data structures to the builder
This is very similar to a project of mine I started long ago yet never worked further on. Builders use phases defined in hooks and phases can define a relative order so the eventual build becomes the topological sort of the phases. Instead of Ruby the builder uses Python. I decided to wait to see what happens with Nickel before putting in more effort.
You can ship a complete NixOS distribution that gets installed in a single WSL import command. A typical NixOS WSL tar is under 1 GB (but can be twice as low in minimal configuration).
I’m interested in using Nix on windows to produce windows-native binaries and artifacts (not WSL-binaries/artifacts).
Some windows-native builds require running on Windows OS, just like macos-native builds require running on MacOS.
Is there something wrong with using powershell for the scripting language? The powershell core is basically the main new scripting system for windows anyway.
powershell is a poor fit due to it being non-bootstrapable and slow (initial startup takes 200ms or something)
Currently, in nixpkgs-architecture team, we have an issue that contributes to this issue, currently we are considering replacing bash with oil shell or ruby
Meson or CMake is not a prereq for building Nix with MinGW, but it is if we want to do no MSVC builds too it is a prereq, and if we are serious about windows I think we should aim for that.