Nix on Windows?

"
Now in Windows 10 Creators Update, a user (with admin rights)
can first enable Developer Mode, and then
"

It does not seem more convenient than just to grant “SeCreateSymbolicLinkPrivilege” to the users who need it

This could be done as part of the installer. Sounds more robust then messing with hard links.

Do you see any other options here except

  1. Use Windows symbolic links (nixbld users must have SeCreateSymbolicLinkPrivilege)
  2. Use unprivileged hard links and store somewhere (in file streams?) information for GC about the “direction” of the links

Are there unprivileged directory hard links? These seem to be a substantial interesting problem for implementation…

When you are building against glibc, you could always patch glibc to treat desktop shortcut files (lnk) as symlinks — at least PocketBook did that for their Linux-based firmware with FAT32-formatted microSD cards, and it worked. I do not say it is a good idea; symlinks are probably better.

1 Like

Actually, there is no choice on how to implement symlinks.
There are symlinks in git repos (for example LLVM’s) and source tarballs, so the only option is to follow Git’s and archivers choice.

A funnier problem is the prefixes added by Nix (not only nix store paths like C:\nix\store\nj8672hwq8r54b9f1njs1i1dwajipncd-material-sprited-animation-view-ios-8af9ada\, but also build roots like C:\Users\User\AppData\Local\Temp\nix-build-chromium-73.0.3660.2.drv-0\chromium-73.0.3660.2-src\) often result in full paths longer than 254 chars. Supporting longer paths requires special effort not only from Nix itself but also from all the programs involved into build process (long paths passed to API must be absolute, must contain no \..\ and be prefixed with magic prefix \\?\).
That means:

  1. there is no reliable ready-made to do cp -r. Windows’ own xcopy does not work with long paths. robocopy does, but it has other bugs (it cannot copy from readonly nix store, so cannot be used on unpackPhase after fetchzip/fetchgit).
  2. stdenv.shell (the script language used in buildPhase, etc) should support long paths. Currently I am using Perl which does not support it out of the box, so I have to use Win32-LongPath-2.2 - Windows file functions that use very long paths and Unicode. - metacpan.org and thus resulting code is not portable. Perl’s own function open, glob, … do not support long paths and cannot be used on Windows reliable, Win32::LongPath’s functions are Windows-only. So I am in doubt what could be a portable stdenv.shell then… nodejs? miniruby?
  3. Third party build tools should be fixed. So far only cmake correctly handled long paths (I did not investigated how, just saw a cmake warning about “path being longer than 255 bytes” but the build succeeded), ninja has the problem (https://github.com/ninja-build/ninja/issues/1514)
4 Likes

Hi, I’m just sorta new to Nix and learning about it.

Is there a tracking issue somewhere for native windows support?

Much like what was said in this comment I am not as interested in WSL since it doesn’t play nicely with various IDEs

2 Likes

Image of Windows with installed native Nix is at
magnet:?xt=urn:btih:8124507E71C42E5496F922589B3FB79D7C9A90F0&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80 (login Administrator, password Abc123)

Note that it is in early alpha and many things do not work as well as on Linux (for example, Nix Store is not protected from writing)

12 Likes

I made a #nix-windows IRC channel on Freenode, BTW.

3 Likes

I got up to half, but I gave up because it was too big. I hope the official version of nix for windows will be released someday.
.
Of course it sounds ridiculous. It might be faster to @volth join ms and make ㅡ.ㅡ. hehe

1 Like

Hi @volth, are you still around? I’ve missed you on GitHub, and interestingly GitHub knows that you had some branches that were ahead of their nix-windows counterpart-forks. I was curious if you’re still working on Nix for Windows, if you could send those commits to us somehow, etc. (I can be reached at cole.mickens@gmail.com or in #nix-windows too if thats better).

2 Likes

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

8 Likes

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:

  • more expressive than Bash (and Perl 5)
  • has a lot of features from Haskell to make FP people happy
  • has excellent Unicode support
  • and (what is rare among scripting languages, because most of them were quickly ported from Unix land) it works well with Windows paths, including symlinks
3 Likes

How big is its closure?

1 Like

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.

1 Like

Also GitHub - google/zx: A tool for writing better scripts

apparently there are posix shells that work on windows: GitHub - AdaCore/gsh: A POSIX shell for Windows.
(untested)

1 Like