Support AbstractFilePath

[mmhat]

This PR adds a new namespace OsPath to the library which contains a version of Path that is a newtype wrapper around the System.OsPath filepaths. As a consequence all functions that took a FilePath as an argument or produced on, or that took/produced a String (e.g. extensions) now use the counterparts from System.OsPath and System.OsString respectively.
toFilePath is an exception to this, it still gives you a System.FilePath.FilePath.
For the implementation I aimed to stay as close to the existing Path modules as possible, that's why there are for example also ports of the deprecated functions included.

As it stands this PR consists of two parts: The first commits are cleanup/refactoring commits of the code that already exists.
Those happened either because something was missing (hie.yaml) or something got in my way (.ghci.conf) or - the biggest part - as a preliminary work before the replication of the various modules. For example, I refactored the test testsuite such that the copy could be easier adapted to the new OsPath hierarchy.

There are some ugly parts where I am not entirely sure if I found the right solution - in particular the aeson instances and everything involving conversion from one encoding to another, where I had to use unsafeDupablePerformIO at some places.

Gently pinging @hasufell @mpilgrem (I noticed to late that you started working on this issue too) and @NorfairKing since I am interested in your feedback specifically.

Fixes #189

[hasufell]

Wrt aeson, also see:

• https://hasufell.github.io/posts/2024-05-07-ultimate-string-guide.html#to-json

Can you point me to the places where you use unsafeDupablePerformIO or do encoding/decoding?

I'm on my phone and PR reviews are hard.

Generally, we shouldn't need to ever assume an encoding. Using decodeFS/encodeFS can be a sign of a bug, but not always.

[mmhat]

@NorfairKing Well, there is a way to relax the version bounds of filepath/os-string to include filepath >=1.4.100.0 as described here.
The problem is that the System.OsString modules shipped with filepath >=1.4.100.0 && <1.5.0.0 do not include two functions I use (all and null); That's the reason for the rather high version bounds.

I am working on (internal) compatibility modules to work around that right now.

[mmhat]

The problem is that the System.OsString modules shipped with filepath >=1.4.100.0 && <1.5.0.0 do not include two functions I use (all and null)

Turns out there were some more functions missing; See compat/System/OsString/Compat/Include.hs.

I added a flag old-os-string that controls whether filepath >=1.4.100.0 && <1.5.0.0, os-string <2.0.0.0 or filepath >=1.5.0.0, os-string >=2.0.0.0 are pulled in as dependencies.

@NorfairKing Can you check again if that works for you too? (Since I am not a Nix user I am particularly interested if it works with that setup.)

[NorfairKing]

@mmhat now I'm seeing this:

       In the dependencies for hashable-1.4.4.0:
         * os-string must match >=2.0.2, but os-string-1.0.0 is in the Stack configuration (latest matching version is 2.0.6).
       The above is/are needed due to path-0.9.5 -> hashable-1.4.4.0

When trying to build with this path with:

extra-deps:
- os-tring-1.0.0@sha256:f1582da15c52761681da87d98c854a0db54049f34d59f74cfec4cc56ad8fbc05,1852
flags:
  path:
    old-os-string: true

We're getting closer though!

[mmhat]

extra-deps:
- os-tring-1.0.0@sha256:f1582da15c52761681da87d98c854a0db54049f34d59f74cfec4cc56ad8fbc05,1852
flags:
  path:
    old-os-string: true

There's a typo : os-tring should probably be os-string... Not sure if that's the source of your problems though.

Which resolver are you using?
I had troubles with the stack configuration yesterday as well: The reason was that the latest LTS snapshot has filepath <1.5 but os-string >=2, and in addition to that the hashable version in that snapshot has also conditional dependencies on both libraries (See the impl(ghc >= 9.2) in the package description.)

[NorfairKing]

extra-deps:
- os-tring-1.0.0@sha256:f1582da15c52761681da87d98c854a0db54049f34d59f74cfec4cc56ad8fbc05,1852
flags:
  path:
    old-os-string: true

There's a typo : os-tring should probably be os-string... Not sure if that's the source of your problems though.

Ah that was a copy-paste error, I had it right in my source code.

Which resolver are you using? I had troubles with the stack configuration yesterday as well: The reason was that the latest LTS snapshot has filepath <1.5 but os-string >=2, and in addition to that the hashable version in that snapshot has also conditional dependencies on both libraries (See the impl(ghc >= 9.2) in the package description.)

lts-22.22, the latest stable release of nixos.
Ideally all of this would "just work" without any flags needing to be set.

[mmhat]

@NorfairKing I added a stack.old.yaml that builds with the old-os-string flag enabled. Hope that helps...

Ideally all of this would "just work" without any flags needing to be set.

Yeah, that would be great. I am not sure why one has to set flags explicitly, but I suspect that Stack solves dependencies without trying to toggle flags? TBH, I have no idea how to work around this issue...

[NorfairKing]

@mmhat for least annoyance, we need to make sure that path "just works" (with default flags) with at least stackage lts-22.22 (the current stable release) and lts-22.31 (the next release, so far).
If we can't do that then we need to look upstream to make them forward compatible with this future release before we release it.
We can't just throw code over the wall and expect it to stick.

Right now I still see this when trying to upgrade only path on a 22.22 project:

       In the dependencies for path-0.9.5:
         * filepath must match >=1.5, but filepath-1.4.300.1 is in the Stack configuration (latest matching
           version is 1.5.3.0).
       The above is/are needed since path is a build target.

Here's another project:

       In the dependencies for path-0.9.5:
         * filepath must match >=1.5, but filepath-1.4.300.1 is in the Stack configuration (latest matching version is 1.5.3.0).
       The above is/are needed since path is a build target.

You can try it out by adding /home/youruserhere/src/path to the packages section of the stack.yaml of https://github.com/NorfairKing/smos on development.

If we can't make this backward compatible then we may have to make this PR should a separate package so that we definitely don't break anyone downstream.
(There is a LOT downstream of this package.)

Edit: This feels like a conversation that would be better suited to a medium with more bandwidth. I want to be respectful of your work as well as downstream dependents.

[mmhat]

@NorfairKing I managed to make the changes backwards compatible to a certain degree; I think this as good as it can get.
The current LTS builds with no additional extra-deps: and no flags:; Just specifiying a resolver: is sufficient.
(See the checked in stack.yaml)

You can try it out by adding /home/youruserhere/src/path to the packages section of the stack.yaml of https://github.com/NorfairKing/smos on development.

Adding the following to extra-deps: yields a successful stack build smos on both the release and the development branch of your project:

- Cabal-3.10.3.0@sha256:4a36954a66769eef90353daa0dbb07d43e49c228281383c7e4134445d495f714,12313
- Cabal-syntax-3.10.3.0@sha256:c2ca36499bf9365726968b1e11a757e6d846c47cdf0c2c26a003698fd3c300fe,7431
- directory-1.3.8.5@sha256:fbeec9ec346e5272167f63dcb86af513b457a7b9fc36dc818e4c7b81608d612b,3166
- filepath-1.4.300.2@sha256:345cbb1afe414a09e47737e4d14cbd51891a734e67c0ef3d77a1439518bb81e8,5900
- process-1.6.21.0@sha256:685bc68759da31b5f152092fe664e1644e84f6dc0ae7a6c143e8564a1d6dafe8,2644
- unix-2.8.5.1@sha256:3f702a252a313a7bcb56e3908a14e7f9f1b40e41b7bdc8ae8a9605a1a8686f06,9808

There is unfortunately no way to drop the filepath >=1.4.300 constraint; But I think it's not too much to ask to add some packages to extra-deps: if one want's to use a snapshot < 22.21 together with a recent upstream package.

If we can't make this backward compatible then we may have to make this PR should a separate package so that we definitely don't break anyone downstream. (There is a LOT downstream of this package.)

Yeah, I know; I myself use path extensively...

Is there anything left I can do to improve this PR?

[NorfairKing]

Is there anything left I can do to improve this PR?

I'm replying asap to that you know I care about getting this merged, but can't review tonight.
I'll see what I can do tomorrow.

[NorfairKing]

@mmhat I left two more little comments. After that I think it's ready to squash, merge, and release.
I'll take care of that once this is ready.
Just let me know when you're ready.

I think I'll be around tonight to get it in, and next otherwise next week :)

[mmhat]

@NorfairKing Ok, this can be merged. Thank you very much for maintaining this library!

[NorfairKing]

Merged and released as 0.9.6.

[NorfairKing]

I can't tell why this is not being marked as merged so I will close it manually.