Handling of multiple roots aka Windows drive letters

[lefou]

I just recognized that we have some discrepancies in os-lib regarding Windows file paths. E.g. we have no clear abstraction over file system roots.

This is not an issue on Unix-like system, as they only have one root which is kind-of un-named and must not be explicitly declared. But for Windows, we typically have multiple roots (e.g. drive letters) and we can't construct absolute paths without them.

There is especially no way to access the drive letter via os-lib API. And there is the open question, whether we should treat it as a first segment or as something more special?

Currently, when we use os.Path.segments, the drive letter is not included. This is consistent with the underlying java.nio.file.Path.iterator API. As a consequence, there is no proper way to re-create a os.Path from all segments on Windows.

This is no issue on Unix-like systems though.

Linux: Gettings all segments and re-construct a os.Path from it works

lefou:/tmp $ amm
Loading...
Welcome to the Ammonite Repl 2.5.5 (Scala 2.13.10 Java 11.0.15)

@ os.pwd 
res0: os.Path = /tmp

@ os.pwd.segments.mkString("/") 
res2: String = "tmp"

@ os.Path(os.pwd.segments.mkString("/", "/", "")) 
res4: os.Path = /tmp

Windows: Getting all segments and re-construct a os.Path does not work

$ ./mill --repl
Loading...

@ os.pwd
res0: os.Path = C:\Users\User\mill

@ os.pwd.segments.mkString("/")
res1: String = "Users/User/mill"

@ os.Path(os.pwd.segments.mkString("/", "/", ""))
java.lang.IllegalArgumentException: requirement failed: \Users\User\mill is not an absolute path
  scala.Predef$.require(Predef.scala:338)
  os.Path.<init>(Path.scala:430)
  os.Path$.apply(Path.scala:388)
  ammonite.$sess.cmd2$.<clinit>(cmd2.sc:1)

[lefou]

@lihaoyi, I wanted to bring your attention to this issue. This is effectively a contradiction to our claim from the project description:

You should not need to drop down to underlying Java APIs, as OS-Lib exposes all relevant capabilities in an intuitive and performant way.

[lihaoyi]

Ah windows...

I don't actually know what the best thing to do here is. How is it most tests in Mill pass on windows despite this? I would have thought such a fundamental problem would cause widespread breakage

[lefou]

I think, we saw it once when running idea tests in CI on windows platform, and worked around it. At that time, I wasn't even aware, that we can't handle it in os-lib. I guess, it's because most users and probably also our CI machine, have their projects on the same drive as their home directory. I discovered the issue when I started to analyze, how to better handle foreign modules in the build.sc wrapper code (com-lihaoyi/mill#2114), which is now probably outdated but maybe still an open issue. On Windows, you can't make files relative to each other, if they belong to a different drive.

[lefou]

Also, the JSON serialization of Mill's PathRef is not persisting the segments but uses the underlying toString and java.nio.Paths.get()

[szymon-rd]

Java's Path has a nullable root. I think we also could add a root: Optional[String], which would be Some on Windows. It could be added as a member to the PathChunk, or maybe as a separate type of PathChunk.