"
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
"
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
- Use Windows symbolic links (
nixbld
users must have SeCreateSymbolicLinkPrivilege)- 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.
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:
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
).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?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
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)
I made a #nix-windows
IRC channel on Freenode, BTW.
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
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).
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)