My last commits are here: Commits · nix-windows/nix · GitHub
GitHub - nix-windows/nix: Nix, the purely functional package manager has 2 working branches, mine and Ericsson2314 which get merged eventually
My last commits are here: Commits · nix-windows/nix · GitHub
GitHub - nix-windows/nix: Nix, the purely functional package manager has 2 working branches, mine and Ericsson2314 which get merged eventually
BTW, Rakudo (Perl 6) might be a good candidate for the language of imperative builders (in place where we use bash
on Linux).
It is:
How big is its closure?
Who cares? The biggest is stdenv
, which includes 14GB of Visual C++.
All the rest are tiny compared to that behemoth.
O.o
I shouldn’t be too surprised given that it’s Windows but still…
I was more curious about it as a replacement for bash elsewhere too because I’m not a huge fan of Nixpkgs being glued together with such a primitive and ancient scripting language.
What would you replace it with? It’s easy to bash…bash…
bash
itself might be no so bad, but it can do nothing: it calls external programs for every simple task.
and there is (at least was 2 years ago) no programs on Windows to do ln -s
or cp -r
(neither copy
not xcopy
not robocopy
nor mingw
’s coreutils were able to, for example, cp -r
of llvm
’s source tree with all their dangling symlinks and unicode symbols in filenames)
What’s the test case for that @volth? I spent several hours playing with the vm image a month or two ago. Got something built even. But I think I was doing something pretty different.
If I fire up msys2, and run pacman -Syu; pacman -S git; git clone https://github.com/llvm/llvm-project; cp -a llvm-project{,2}
, it all completes successfully.
The problem was not compile llvm
successfully but to calculate sha256
for fetchurl
and friends without losing files. In llvm
case those dangling links are among test cases (and that is why they are so weird intentionally), their disappearance does not hurt the build. But affects hashes.
apparently there are posix shells that work on windows: GitHub - AdaCore/gsh: A POSIX shell for Windows.
(untested)
May I add Lua to the list?
It is very small
It is very fast
It is easy to bootstrap
Its syntax could be better, if that’s a deal-breaker stuff like moon/yue script exist (GitHub - hengestone/lua-languages: Languages that compile to Lua)
Last time I seen Lua, it was compiled for Windows using MinGW.
So the same problem as Python and Perl (when without special Windows libs): no paths longer than 255 chars and bad symlink support.
I am a fan of Lua for this too. GitHub - rjpcomputing/luaforwindows: Lua for Windows is a 'batteries included environment' for the Lua scripting language on Windows. NOTICE: Looking for maintainer. shows MSVC lua is no problem.
Absence of function to get size of a set in both Nix and Lua reveals some influence
There is no problems with MSVC. Perl, Python (and probably even Bash) can be compiled by MSVC.
The problem is the filesystem library must support long file names and symlinks (including dangling and recursive).
Remember, there is no reliable cp -r
on Windows. All software I tested: from built-in copy
and xcopy
through MinGW bash
and coreutils
, to 3-rd party robocopy
do fail on doing cp -r
with real-world directory structure which has both long filenames, recursive symlinks and non-printable characters (such as checked out LLVM and Chromium monorepos), so cp -r
, ln -s
, … have been written in Perl with some external modules (and even this choice required patches in C code of those modules).
The test question for Lua, Rakudo, NodeJs, … is as such: can it be used to write cp -r
and ln -s
which won’t fail on long filenames, recursive symlinks and non-printable characters ?
On Linux, I am currently on stripped Nixpkgs with only ~3000 packages to ease maintainability.
Anyway, it has lost compatibility with mainstream Nix (it small nuances, like { name = "xx"; passthru.name = "yy"; }
is verboten). I will try to replace bash
with something else, keeping in mind eventual merging that Nixpkgs-lite/Linux
with Nixpkgs/Window
. So far, Rakudo is the cutest but a bit exotic option. JavaScript is more practical.
Sounded nice as first, though: Running scripts without extensions errors if they are on a RO filesystem · Issue #176 · google/zx · GitHub
Therefore a bit nasty to deal with when on nix.
Even leaving Windows aside, there is a need for a scripting language to replace Bash in builtins.exec
(why? 1. bash alone is not enough, bash does almost nothing except running other program, which have to be build somehow … so it quickly evolves to maintaining another “bootstraping” copy of <nixpkgs>
for programs to run in builtins.exec
2. safety. builtins.exec
code runs under user account and can do weird things, Nix own scripting engine could limit what paths the code can access, etc. Guix can happily use Scheme everywhere, but we have to use Bash every time when we need imperative code). As an embedded scripting language, it has to use the I/O functions used by Nix and therefore works in Windows if Nix is running there. And it gives us additional options to choose the language: there are much more embedded languages than standalone ones. But here 1:1 type matching with Nix would be desirable, and it is the weak point of JavaScript which lacks Int64.
Just to note: although Ruby does not support Windows well, Chef made the work to support UTF-16 strings, long file names and symlinks: https://github.com/chef/chef/tree/main/lib/chef/win32
So Ruby looks like a good candidate to replace Bash in build scripts. Maybe on Linux too.
It has bigger fan base than Perl, and… Homebrew uses Ruby - that might simplify copy-pasting of buildPhase
from there
PS: also, embedding MRuby into Nix might allow syntax like
buildPhase = do
# ruby code here
end;
instead of concatenating opaque strings with Bash
inside (“do
” can also be read as “here begins something imperative” by people used to Haskell)
don’t you need admin access to create symlinks on Windows? this basically ruins any attempt at scripting symlinks, and why msys2 has a really bad workaround (it copies files instead).
IMHO adding an imperative DSL directly to nix makes the most sense, why can’t we just use nix directly instead of using an alternative language, embedded inside a nix-script?
Python is terrible for scripting external apps, I really hate using the subprocess module.
To make another bad suggestion: how about haskell-turtle? Turtle.Tutorial