2024-02-05 Nix team meeting minutes #121

Development Nix
1

In the wake of FOSDEM (and meeting 120 which was cancelled), we had only three attendees, so we decided to focus on technical reviews and decide about @Ericson2314’s Windows support contributions.

Attendees: @edolstra, @Ericson2314, @roberth

Nix on Windows discussion

Context: John has been working on refactors to enable a MinGW port.

Do we want this?

  • (+) If we support the three major OSes, Nix can be build infra for all software, including those that have (some degree of) native Windows support, such as GHC.

  • (+) Ericson2314 believes the effort creates interest

  • (-) Previous cygwin support had no real users

    • Hopefully MinGW being more “real” than CygWin is a significant difference here.

  • FWIW GitHub - microsoft/vcpkg: C++ Library Manager for Windows, Linux, and MacOS Microsoft’s own new package manager for windows emphasizes cross platform portability

  • @roberth

    • Chicken and egg problem: Nix needs to make the first move

  • @edolstra: What about a prototype branch?

  • Roadmap

    • Path refactorings
    • Misc filesystem stuff
      • I stripped back to using more MinGW/ucrt functions, but ideally should go back to using native Windows functions for symlink support
    • libutil process.cc
      • This is completely separate code, not available in my current PR, would need too add later, used by build.cc
    • build.cc
    • Sandboxing? Windows has some stuff for Docker
      • Want to investigate that
      • But would start without

Let’s decide who works on this / how much?

Considering the roadmap, we believe the CanonPath-related changes are most significant and worth doing an in-meeting review. Further work will be async, so that the meetings can focus on higher priority work without blocking the Windows effort.

Support Windows paths in `canonPath` and `absPath` without messing up `CanonPath` by Ericson2314 · Pull Request #9767 · NixOS/nix · GitHub

@Ericson2314:

  • CanonPath should be the platonic ideal path

  • PosixFileAccessor

    • Rename to NativeFileAccessor
    • Have std::filesystem::path root/prefix

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

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

Agreed CanonPath::fromCwd must go

Overload `/` to mean path append; alternative to `path + "/" + "foo"` footgun · Issue #7301 · NixOS/nix · GitHub

@roberth: A small issue for the last couple of minutes of the meeting, tangentially related.

  • path / "string" is a good idea (@Ericson2314, @edolstra, @roberth)

  • "string" / "string" probably good for consistency.

    • We want to use string for “abstract” paths such as those in NixOS configs
    • Slightly trickier "1.0" / "2.0"

  • Feels like a gimmick, but solves a real problem

  • @Ericson2314: let’s talk to the tvix people as well

2 Likes