🎉 All dependencies have been resolved !

A few meetings ago @edolstra had asked whether it would be better to go straight to using std;:filesystem. I would indeed like to try that, but rather to it as a follow-up step.

(This PR more straightforwardly preserves behavior by reusing code, and increasing test coverage. We can afterwards try std::filesystem::weakly_canonical with the test suite expanded in this PR, and see if it does the same thing.)

I'm pretty wary about adding a lot of complexity to support Windows, if we haven't even decided whether we want that, what that would look like, and whether there is sufficient interest to justify the complexity. (Having no access to Windows development machines, I really don't want to maintain code with a lot of WIN32 #ifdefs.)

It might be better to develop a Windows proof-of-concept on a separate branch for the time being.

If we haven't even decided whether we want that, what that would look like, and whether there is sufficient interest to justify the complexity.

There are now some years-old separate branches in https://github.com/nix-windows/nix. I did write up that document. I am trying to minimize the CPP by dropping features to start, focusing on the unit tests, etc. and using more std::filesystem (but I think taht is best after the initial unit test push).

We can try asking the Nix community some more, but while I expect people to be passively interested I wouldn't expect much up-front commitment. The Windows and Unix industries are fairly disjoint, and plenty of people are happily avoiding Windows (certainly myself included for any downstream project I have full control over.) For me, this is more an expanding into new areas thing / growing the Nix community in new ways, than making something existing community members will immediate jump on.

(Having no access to Windows development machines, I really don't want to maintain code with a lot of WIN32 #ifdefs.)

I do all the development cross compiling from Linux, and will be creating a derivation to run the unit tests with Wine before merging something more significant. I would be fine simply not testing native Windows builds for the imminent future (a long trial mode) so there is no build/test failure that can only be reproduced on them.

In the meantime, #9881 is the first part which should be worthwhile with or without Windows.

@edolstra Discourse is not letting me reply to myself another time, so if you could comment in https://discourse.nixos.org/t/nix-on-windows/1113 saying you're trying to gauge user interest, that would be appreciated.

We agreed I would try to get rid of CanonPath::fromCwd first.

Discussed in meeting today

// split path, trying to make the native prefix as short as possible, and CanonPath suffix as long as possible
std::fs::path -> (std::fs::path, CanonPath)
    
// feed native prefix to NativeInputAccessor to create SourcePath
(std::fs::path, CanonPath) -> SourcePath

-I foo=D:\asdfasdf
-I bar=C:\asdfasdf
-E '((import <foo>) (import <bar>))'

SourcePath rootPath(CanonPath path);
SourcePath rootPath(std::fs:path path); 
SourcePath rootPath(std::fs:path path, cwd ...)

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/2024-02-05-nix-team-meeting-minutes-121/39340/1

Thanks!