Problems when trying to use the package with stack

[andrewerf]

It seems that the version indexed by the Haskell LTS (which is used by stack) is the one with absent OsPath feature: https://www.stackage.org/lts-20.25/hoogle?q=filepath.

This creates an obstacle to use this feature, which at first sight seem quite nice. Is there a reason why the latest version with OsPath is not marked as preferred and not included in LTSs?

[hasufell]

I don't know. I'm not a stackage curator.

Filepath 1.4.100.1 is first shipped by GHC 9.6.1.

With cabal I can easily use it with older GHCs as well.

@mpilgrem @juhp

[juhp]

The version in Stackage should just be the included package version directly from GHC.
Stackage does not try to override any core library versions: the current LTS 20 is based on ghc-9.2
which ships with filepath-1.4.2.2 (as does ghc-9.4 in Stackage Nightly).

I think it may be possible to override that in your stack.yaml file perhaps:

resolver: lts-20.25
extra-deps:
  - filepath-1.4.100.3

though I haven't tried - but it will obviously cause various core libraries to be rebuilt.
Once Stackage Nightly moves to ghc-9.6, you will get newer filepath "for free".

Hope that helps

[hasufell]

but it will obviously cause various core libraries to be rebuilt

Which should be fine, since existing API was untouched.

[mpilgrem]

I've not much to add to @juhp's explanation: as he says, the set of packages represented by a Stackage snapshot are (a) those that come with the specified version of GHC (the 'boot packages', including filepath) and (b) others. If you need a different version of a package, you can specify it as an extra dep; that is also true of most boot packages (not all; you can't 'replace' base, for example). What I will add is: if you 'replace' a boot package, Stack will 'prune' other boot packages that depend on that boot package. 'Pruned' boot packages will also need to be specified as extra deps, if you depend on them. For example, if you are on Windows, Win32 depends on filepath.