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.
There’s one benefit of supporting windows that I can’t stop thinking about:
Library creators sometimes need non-library external applications that they run internally (for example an image manipulation library might call imagemagick under the hood). Such external dependencies are usually not handled by the languages package manager very well. For NPM packages for example, the packages usually have their own scripts to download such applications as pre built binaries from somewhere for the specific platform they’re currently on, which means a lot of trouble when nixifying such packages.
The solution would be simple: Provide package creators a way of defining such dependencies with nix, and when nixifying the package, this could be respected. Nice! This could be so convenient, that it quickly could become the default way of dealing with this. The only problem: if it doesn’t work on windows as well, they’ll still have to do it manually there. And then, why even bother with nix?
If nix worked on windows this would not be a problem, and package creators could focus completely on specifying dependencies with nix. This would dramatically simplify building packages with nix in the long run and would also benefit Linux and Mac.
I want this source to setup my workstations, servers, etc
I want this source to run on windows, Linux, and Mac. where i want it to configure those platforms.
I only expect to create small wrapper tools curl blah | sh or the powershell iex equiv to kick start the setup on a fresh machine.
I read a lot about people claiming “omg it works on windows via wsl2”, but when you look at what they’re doing… it’s no different to what they do on linux, completely disregarding the configuration and provisioning of the windows side of things.
I had seen only one mention so far (in this thread i think) that since you could execute windows binaries from within wsl2, that there could perhaps be a way to make nix do windows configuration that way ?
I’d also like to thanks @wegank a lot for helping out with getting readline working on Windows, so we can (hope to) have a nix repl. That is the final dependency that needed Nixpkgs porting help (since we are skipping lowdown for now).
The number of Nixpkgs PRs and backports for this is rather dizzying, so I won’t link them here :D.
This looks like great starts…
Do we have a project github where we can share on this?
e.g.
- Considering system packages/features (terminology changes between workstation and server versions for no good reason via DISM.exe)
Pursuing is (beta/preview) M$/Pwsh DSC (Desired State Configuration) becomes useful enough to add to Nix on windows.
I think maybe she’s excited about the possibility of an impure Nix module system for Windows, like Nix-Darwin is for macOS, where the parts that require configuring the underlying OS could rely on DSC.
But yeah, DSC is like Puppet or Chef. It’s an interface for defining configuration options that can be invoked declaratively, but it’s basically powered by bits of PowerShell scripts and it’s on the authors of DSC modules (or whatever they’re called) to ensure those scripts behave idempotently.
