Pathos is cross-platform. Meaning the same code written against it compiles and functions in the same manner without #if os(). It's API selection is comparable to Python's os.path (not as broad because Pathos focuses solely on manipulating the VFS).
If you are trying it out on Windows, please file any bugs you encounter :)
Very cool! I have a couple of questions/suggestions that are kind of more about how to work with paths in general, but I’d be interested to hear what you think of them:
What do you think about adding a function to tell if 2 paths point to the same file?
There are times when you want different paths to the same file to act like different files, but there can be times when you're doing some expensive processing that is largely location-independent. In those situations, it can be helpful if you are able to recognise that you saw this file already under a different path, so you can re-use some/all of the results you calculated previously.
realpath can help for symlinks, but not for hard links (I think that’s right...?). Supposedly, the better way to do this is to stat the file and compare device and inode numbers, and that should work for both symlinks and hard links. It would be nice if there was a function that made this simple and obvious.
What do you think about making the working directory a library-internal property, rather than using the OS’s working directory?
One thing that has bugged me for a while is that the OS’s working directory is a piece of process-wide, mutable state. So if you do something like try Path("markdown-source-dir").asWorkingDirectory { ... } to set different working directories from 2 functions executing in parallel, the results are not predictable. But it isn’t like we really need any OS magic to understand what the working directory does - Path.absolute already knows exactly what it means and what to do with it.
So why not absorb it in to the library, and say that it only applies to other pathos functions? That way, it could become a thread-local (or Task local, once we have native concurrency), and getting/setting the working directory could possibly become non-failable.
Absolutely. This actually was in an earlier version of the library. It was implemented by comparing inode numbers I think. It's not in current version because:
I haven't figured out what an equivalent function should do on Windows
I'm not aware of any usage of it in production (but again, entire user behavior is unknowable, so I'm glad you bring it up with a brief look).
The reality is when it comes to file system, everything is shared and mutable by default. In comparison, the CWD being such for a single process isn't bad at all :P. I think I understand your reasoning for this suggestion, but people expect this API to exist generally (my mental model is scripting a shell), regardless of whether it's the best way to achieve what they want.