Is anyone still using Nix on Cygwin?
I am working on changes that would likely break any remaining support for Cygwin, and there is no way to build or test Nix with Cygwin. It is not in the list of supported platforms.
I am trying to add support for native Windows (using mingw-w64).
I don’t think it is currently used by anyone, so some breakage might be okay. However, we definitely want to make it easy for someone to readd support in the future. In theory it should be much easier to support than mingw-w64 & require less patching, but it’s not used very much any more with WSL available.
In our company we use every day nix on cygwin since years. Some months ago I also reported a bug in nix 2 that got fixed, and since then we use the latest nix just fine.
Of course we use it with non-public nix expressions that involve Microsoft compilers and so on.
Please don’t break nix on cygwin.
On the other hand, we welcome a native nix for Windows too.
That’s pretty impressive. Do you have any articles or documentation about it?
I’m specifically interested on how to build, install and run Nix on Cygwin. I would also love to know how you’ve integrated it with VS and how well it works compared to other build and packaging tools or compared to Nix on WSL.
Sidenote: I feel like removing support for something is basically guaranteed to decrease portability?
I.e. you WILL end up with something that doesn’t port eventually.
As there are some Windows users, what do you think about adding support the drive letter to the Nix Parser when it parses paths?
I filed an issue 6 months ago https://github.com/NixOS/nix/issues/2603 and get no reaction, concluding that noone cares about Windows or Cygwin.
Ah no I don’t have any public example. Our nix files are pretty simple though; we basically have a replication of vsvars in bash syntax, and we try to support multiple compiler versions, SDK versions, ucrt, etc. To have some reproducible results on fixed nix hashes, at least.
But we don’t build nixpkgs with those recipes; only the libs/programs we use for our development. Nothing special - some open source mathematics and i/o libraries. We even don’t use nix-shell for the development environments but we have recipes for scripts that behave like nix-shell.
By now cygwin nix has been enough so I never cared about the non-unix paths. But some colleagues have a desire for a cygwin-less solution because the programs run faster in either WSL or native windows, and then this may have a role.
It’d be nice that a cygwin nix could evaluate the same kind of recipes as a mingw nix, and the paths worked just fine, not requiring different recipes. The same way one can use git for mingw or git for cygwin, in a windows machine.
EDIT:
1st time I use this discourse, and created an account only to answer this topic. It says I reached the limit of Replies in this topic and that I should edit my previous replies instead. The last nix we use 2.0.x doesn’t need libeditline. So maybe someone broke the normal cygwin build by adding that.
Sharing the same store between Cywin, WSL (and a potential native Nix) sounds like a great idea. I might give it a try, but I can’t think of a maintainable way to get either symlinks or GC to work correctly.
How do you build Nix on Cygwin, without Nix? I was not able to get the latest tarball to build: ./configure doesn’t find libeditline and doesn’t recognise libreadline
I have native Nix fork at https://github.com/volth/nixpkgs-windows https://github.com/volth/nix-windows (with MSVC and Perl as stdenv.shell because there is no bash working properly with Windows path names, all bashes require some sort of FHS emulation (moreover there no perl nor coreutils working properly with Windows long paths, build process of some native program use long paths which stdenv has to me able to cp -r and rm -rf at least). Perl + some 3rd party modules Win32::LongPath + patches not accepted by upstream was the closest shell to support all kinds of paths. Perhaps I had to use Powershell.
It builds Perl, Python, LLVM, Chromium, Win64Dbg, …
Mingw binary packages can be unpacked to c:\nix\store as-is, without recompilation or patchelf’ing, there is an updater script for them.
My goal was mainly to build Chromium with native Windows font rendering (free of freetype ugliness), so the development is stuck after the goal was achieved.
@volth That is amazing work! I would love to use it and complete it to make it easier to merge upstream (if there’s enough support for it). I see there’s a few bugbug/??? comments and no symlinks. I had been considering a busybox-w32 + clang-cl stdenv.
I was able to build on Cygwin, using -lreadline -DREADLINE. I’m working on getting some of the tests to work. I’ll try to figure out what other dependencies I needed so I can write some docs.
The big refactoring needed in upstream is replacing Nix’s class Path with something character-size (char or wchar_t) and delimiter (/ or \) agnostic, for example boost::filesystem::path.
It is what is difficult to solve by #ifdef _WIN32, because Path is everywhere.
That issue above was supposed to be the first step 
Another cluster of issues: Nix build process (long prefixes in c:\nix\store\xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx, symlinks everywhere, long environement variables, …) reveals many bugs in Windows utilities, not only hacky ports like msys bash, but also in native ones, such as 7zip 7-Zip / Bugs / #2174 directory symlink unpacked as file symlink and ninja https://github.com/ninja-build/ninja/issues/1514 and Win32::LongPath https://github.com/rdboisvert/Win32-LongPath/issues/8 https://github.com/rdboisvert/Win32-LongPath/issues/10
They are still unfixed in the upstreams.
Rewriting something like https://github.com/NixOS/nixpkgs/blob/dd422da4b868c3fce96ee55a7730a81ca6cec9c8/pkgs/stdenv/generic/setup.sh to busybox-w32 shell would result in forking of busybox
I was installing nixos at the end of last year.
While using Windows or another Linux.
the early summer months of this year
We used nixos in earnest.
The reason for the initial use is that regardless of the company’s development date, the duration of the re-recovery when formatted and the integration of internal complex developments is simple, so I became a full fan.
Company work is webgl of Unity3d, I came back to Windows a few days ago (I already had a Windows disk, I used to use multiboot, but only nixos).
Now I accidentally blew up a nixos disk.
(Because I was baking iso from msys2 to dd in usb…) It occurred.)
So, I was a bit out of my mind, but I came to my senses.
.
I installed nix + home-manager on wsl2 in this opportunity.
It was okay, but…
It was not as simple as nixos configuration.nix.
because
I like to customize it myself.
And
I like to set everything in one setup file. Especially for me.
You do not use the nix-shell repl, and you may not know how to use it.
The style to change settings and rebuild.
.
The nixpkgs-window that @volth have successfully installed and succeeded in this opportunity.
I want to try it on msys2.
.
How do I get started?
I don’t know perl.
Some thread Windows MinGW support · Issue #1320 · NixOS/nix · GitHub
tells you you use a perl. I wonder When installs nix on the window, perl why and where need.
https://github.com/volth/nix-windows
It’s just…
I think you compiled it into msvc…
Because of unity3d and rhino3d, I really want to use nix in Windows 10.
I want to get away from wsl2 and home-manager.
^,.^ thanks.
(post withdrawn by author, will be automatically deleted in 24 hours unless flagged)
