Ecosystem upgrading to filepath-1.4.100.0 may break HLS

[kokobd]

A new alternative for OsPath is released in filepath-1.4.100.0, and will be shipped with GHC 9.6
Now, given that:

1. filepath-1.4.100.0 supports from ghc 8.0 to ghc-9.x
2. Upstream library authors may feel free to bump version bound to filepath ^>= 1.4.100.0, without upgrading their major version, if they can keep backward compatibility to the API
3. ghc-9.2 and filepath-1.4.100.0 can not co-exist, as this requires a rebuild of ghci-9.2, but ghci is very outdated on Hackage

Then, if everyone upgrades filepath to support OsPath, HLS can not upgrade any of its dependency that depends on newer version of filepath. We will be pinned to the ecosystem where OsPath hadn't come out, and no longer be able to receive upstream bug fixes.

Have I made any mistakes in the analysis? What should we do about this?

[kokobd]

And reinstall ghc has its own risk about ABI compatibility. In https://gitlab.haskell.org/ghc/ghc/-/issues/21887#note_443890, Ben Gamari pointed out ghc doesn't support reinstall as a normal package now. (so haskell.nix has done something special to make it work in that env)

[michaelpj]

Then, if everyone upgrades filepath to support OsPath, HLS can not upgrade any of its dependency that depends on newer version of filepath.

This is true any time there is a significant upgrade to a deep dependency. We can be held back by GHC (as in this case), or by some other dependency of ours which fails to upgrade. I guess being held back by GHC is more problematic, since we can't really hurry up the process of getting newer GHC versions.

I think we may just have to live with this: older versions of HLS will be stuck with older versions of dependencies. This is a good reason to make sure that our critical dependencies (e.g. lsp) continue to work with old filepaths.