vibe.core.path: Cross-platform normalization / equality ?

[Geod24]

I have been trying to adapt dub to the newer path modules, but have hit a lot of issues:

1. The new module isn't always normalized, and there is nothing to force auto-normalization (worked around);
2. The new module is (more correctly) platform-specific. Types like Dependency have a NativePath in them, and this can lead to differences in the generated dub.selections.json. On the other hand, we do want to accept platform-specific paths for some users;
3. Writing tests is difficult due to subtle differences in how path separator are handled. for example a/b/c and a\b\c don't compare equal, although they are on Windows.

@s-ludwig : Is any of the above in scope for vibe-core's path module ?

[s-ludwig]

The new module isn't always normalized, and there is nothing to force auto-normalization (worked around);

I didn't even remember that the old code performed implicit normalization when concatenating. IMO this is, among other implicit operations, definitely unsound for the general case. However, in an application specific context that may make perfect sense, so the workaround in DUB probably functionally makes sense. I'm not sure how to integrate that in a nice way into the GenericPath API, do you have any idea here? NormalizedNativePath would work, but isn't exactly "nice".

The new module is (more correctly) platform-specific. Types like Dependency have a NativePath in them, and this can lead to differences in the generated dub.selections.json. On the other hand, we do want to accept platform-specific paths for some users;

We should probably force PosixPath for dub.selections.json, which should work fine for all relative paths. Absolute paths will be broken across systems anyway, so outputting a warning and making a special case for them is probably mandatory, though. The only general solution that I can think of right now would be to use URL(NativePath)/URL.toNativePath (absolute) or cast(InetPath)/cast(NativePath) (relative) for storing a mostly platform-agnostic path.

Writing tests is difficult due to subtle differences in how path separator are handled. for example a/b/c and a\b\c don't compare equal, although they are on Windows.

I kind of agree, but really that just reflects the subtle differences in path handling across platforms (such as Posix paths being able to contain "\\" as part of a file/directory name). But shouldn't this also be solvable by the/an auto-normalization wrapper? I really should have a look at the existing workaround...

[Geod24]

I'm not sure how to integrate that in a nice way into the GenericPath API, do you have any idea here?

I have a struct Normalized(Path) template that wraps or forward. Not very nice either and doesn't work well with URL.

We should probably force PosixPath for dub.selections.json

Probably, it's just a pain to go through that deprecation cycle when I am just trying to upgrade dependencies.
Note that I have found myself wanting to have a RelativePath / AbsolutePath types more than once.

But shouldn't this also be solvable by the/an auto-normalization wrapper? I really should have a look at the existing workaround...

The "wrapper" is starting to feel more like a custom implementation at this point.

[s-ludwig]

RelativePath / AbsolutePath

Sounds useful, would definitely require proper sub typing to make it usable, but hopefully alias this would work sufficiently for this.

The "wrapper" is starting to feel more like a custom implementation at this point.

True, it's really more of a workaround than a desirable part of the code base.

I'll sketch up an API when I get the time, maybe it's actually not that bad to add all of these special types as long as sub typing works everywhere and you can still just use plain NativePath etc., if you don't care about the other semantics (i.e. there would be compatibility overloads wherever needed). The normalized variants might just add an N suffix to make it less painful to use.