added os-string flag to cabal file

[BebeSparkelSparkel]

Allows using filepath version >=1.5.0.0 and the new os-string package

[amigalemming]

For the PVP the os-string version range looks too loose. It should be <2.1.

[BebeSparkelSparkel]

@amigalemming fixed the version bound

[LaurentRDC]

Why can't this PR just be an upper version bound update on filepath?

The OsString type is re-exported from filepath, so there's no need to include another dependency (in this case, os-string).

[phadej]

@LaurentRDC it probably could, but then users of old filepath and new os-string (which is possible combination AFAICT) won't get an instance on the types in os-string (there will be two different OsStrings).

---

I'm undecided whether I want to allow that option (and as it is, this PR wont: if you want os-string you are forced to use new filepath, even on old GHCs), or whether dependency on os-string should be unconditional (and code to be written).

I'll decide when GHC-9.10 is closer to release, when it's forced.

Until then, indeed, things "seem" to work if you just relax bounds (e.g. with allow-newer), so I'm not in a hurry.

[josephcsible]

default: False here interacts badly with --allow-newer. Trying to do any builds that use that will result in our flag being false but using a version of filepath that needs it.

[hasufell]

There's no way around it. It has to be an automatic flag.

[josephcsible]

I know it has to be automatic, but can't it be default-true automatic?

[hasufell]

I find it hard to reason about this. Also note that all the other packages have the default as False.

This strategy is also suggested by Cabal-syntax, which we derived this from: https://hackage.haskell.org/package/Cabal-syntax-3.6.0.0

Maybe @Bodigrim knows more.

[Bodigrim]

@josephcsible if you are already passing --allow-newer you can pass -c 'hashable +os-string' as well.

[josephcsible]

@Bodigrim I know I can do that, but I don't want to have to do that for every single cabal install --allow-newer that I ever run in the future that pulls in hashable.

[josephcsible]

Another idea: if we really want to keep the flag default: False, then could we do what QuickCheck does, calling the flag something like old-filepath, and having True be the legacy path and False be the modern path?

[Bodigrim]

I don't know any particular reason to stick to default: False, but I also find optimizing for --allow-newer to be a weak justification.

Ultimately, I think that

dependency on os-string should be unconditional (and code to be written).

is a better solution, in which case the default value of the flag would be immaterial for --allow-newer.

[josephcsible]

The solution that was just merged in #293 doesn't cause this problem, so I'm happy with it.

[andreasabel]

I'd put filepath >= 1.4.1.2 && < 1.6 here and then filepath < 1.5 into the else (and delete filepath from the if part).
This style is slightly more concise. And it is apparent that we always depend on filepath.

[andreasabel]

@phadej : Would it be possible to release this now (or some other fix of the problem)?

Evaluation of GHC 9.10 is hampered atm since 1000 projects depend on hashable. Getting these unstuck would expose GHC 9.10 to more testing which would help the GHC 9.10 release process.

[hasufell]

GHC 9.10 prerelease is out and I'm running into this in ghcup-metadata CI.