Support Windows paths in canonPath and absPath

[Ericson2314]

Motivation

canonPath and absPath work on native paths, and so should switch between supporting Unix paths and Windows paths accordingly.

The templating is because CanonPath, which shares the implementation, should always be Unix style. It is the pure "nix-native" path type for virtual file operations --- it is part of Nix's "business logic", and should not vary with the host OS accordingly.

Context

Depends on #9759

Priorities and Process

Add 👍 to pull requests you find important.

The Nix maintainer team uses a GitHub project board to schedule and track reviews.

[dpulls]

🎉 All dependencies have been resolved !

[Ericson2314]

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.)

[edolstra]

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.

[Ericson2314]

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.

[Ericson2314]

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

[Ericson2314]

@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.

[edolstra]

Can't we get this from NativePath and save a #ifdef?

[Ericson2314]

Yes, though then I couldn't rely on "easy" literal concatenation. Also note that FS_ROOT we still cannot get from it because on Windows it is an arbitrary choice of drive just for testing purposes.

[Ericson2314]

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

[roberth]

Discussed in meeting today

@Ericson2314:

• CanonPath should be the platonic ideal path

• PosixFileAccessor

  • Rename to NativeFileAccessor
  • Have std::filesystem::path root/prefix
    • @edolstra OK, internal drive

• It'd be ok to specify installables on multiple drives in one CLI.

  • In the language this won't be observed, except the root paths not being equal, just as we want to do with path values from fetched repos (lazy trees)
  • Drive letter is not observable within the language

• In the legacy model, we don't seem to have a particularly good way to represent paths on multiple drives, because the legacy CLI uses a single big / InputAccessor.

• @Ericson2314: even store paths could be independent roots, avoiding the exposure of their "mounts" into the store / the storedir

  • @edolstra: We might just require that everything in an invocation is on the same drive.

// 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>))'

• @Ericson2314: fine either way with the legacy impure eval not working on windows or working on windows.

• Support Windows paths in canonPath and absPath #9767 's WindowsPath and UnixPath are not path types but "trait types" (C++ template shenanagins)

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

Agreed CanonPath::fromCwd must go

[nixos-discourse]

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

[Ericson2314]

Thanks!