Deprecation of System.OsString in 1.4.200.1

[sol]

At the risk that this will turn into a rant...

When migrating form GHC 9.8.1 to 9.8.2 I'm confronted with:

Deprecated: Use System.OsString from os-string >= 2.0.0 package instead. This module will be removed in filepath >= 1.5.

So yeah, moving stuff into separate packages can make sense. But wait, why doesn't filepath just, re-expose that module from os-string? Probably because they wanted to add the deprecation message? But this means that we will end up with clashing module names, uhhh... whatever, do I really care? Just use PackageImports and be done with it... oh, wait, WHAAAAAT, filepath does not even depend on os-path???

So what exactly am I going to do with this deprecation warning, except for ignoring it?

And how useful is a deprecation warning that provides a "course of action" that will result in compilation errors in all but the most exotic cases. How useful is a deprecation warning that you can only ignore, where there is no sensible action to take?

So what I'm going to do is add a OPTIONS_GHC to every affected module, to ignore the warning. This is mostly harmless, except for that it maps any other deprecation warnings, deprecation warnings that may provide actual value... and then, down the road, when I transition to a newer version of GHC / filepath I'll have to remember to remove those
OPTIONS_GHCs again...

Sounds like a lot of wasted effort to me... for what?

[hasufell]

But wait, why doesn't filepath just, re-expose that module from os-string?

Because the OsString stuff has morally nothing to do with filepath and both of them should be able to evolve separately.

If we re-export, we're tying it to the os-string PVP.

But this means that we will end up with clashing module names

See https://hackage.haskell.org/package/os-string-1.0.0 for examples how to avoid module clashes:

flag os-string
  description: Use the new os-string package
  default: False
  manual: False

library
  -- ...
  if flag(os-string)
    build-depends: os-string >= 2.0.0
  else
    build-depends: filepath < 1.5, os-string < 2.0.0

I suspect what's really causing issues is that cabal doesn't handle boot packages well: haskell/cabal#9669

So users get overly exposed to filepath versions that are considered obsolete already.

[sol]

Are you implying that the current situation was intended? That this is not a major screw up or oversight?

ghc depends on filepath. Is there a way to depend on both ghc-9.8.2 and import System.OsString without ignoring deprecation warnings?

[hasufell]

Are you implying that the current situation was intended? That this is not a major screw up or oversight?

Yes. That's the same thing that was done with Cabal-syntax split and I asked several people beforehand on how to do a package split.

Do you have a better way?

ghc depends on filepath. Is there a way to depend on both ghc-9.8.2 and import System.OsString without ignoring deprecation warnings?

Can you share the project you're trying to build and what you think is wrong? I'm having a hard time deciphering what you're trying to do.

[hasufell]

and I asked several people beforehand on how to do a package split.

haskell/core-libraries-committee#221

[sol]

ghc depends on filepath. Is there a way to depend on both ghc-9.8.2 and import System.OsString without ignoring deprecation warnings?

Sorry, maybe I was too brief here. I'll spell things out in detail, at the risk of boring you with things that you already know.

My point is this:

1. ghc depends on filepath
2. For that reason, if you (transitively) depend on ghc you can't upgrade filepath
3. For that reason, no, there is no way to depend on both ghc-9.8.2 and import System.OsString without ignoring deprecation warnings.

This has nothing to do with haskell/cabal#9669.

So users get overly exposed to filepath versions that are considered obsolete already.

While in some situations it's indeed possible to upgrade boot packages, that's not true in general.

Some boot packages are not upgradable, e.g.

• ghc
• template-haskell

Both of them depend on filepath. Depending on any of those makes filepath essentially non-upgradeable. Again, that's the case regardless of haskell/cabal#9669.

I suspect what's really causing issues is that cabal doesn't handle boot packages well: haskell/cabal#9669

With what I said above, I hope we can agree that this is not the case.

I am not going as far as saying "filepath is never upgradable", but in many situations it is indeed not upgradable. For it to be upgradable, you can't depend on some other boot libraries, use TemplateHaskell.

So arguing that the filepath version that ships with the latest version of GHC is "considered obsolete already" is too opinionated for my taste, as it implies other things, like don't use TemplateHaskell and don't depend on ghc.

[sol]

Apparently, template-haskell vendors filepath by now.

[hasufell]

Both of them depend on filepath. Depending on any of those makes filepath essentially non-upgradeable.

I tried and I can depend on template-haskell just fine while requesting a newer filepath.

The situation around ghc is unfortunate, but I don't see how that is my problem. I don't maintain that package. It's a wart, but I can do nothing about it.

[sol]

You are maintaining filepath though. And it would be easy to avoid this friction, e.g. not adding the deprecation message in the first place, re-exposing from os-string, you name it.

It's ok to make mistakes, everybody does. But if you still were to imply that there is nothing wrong, everything as intended, then again, I think that that would be too opinionated for a boot package.

It's nice to have everything nice and tidy, but if we as a community don't sustain ourselves while doing so, and in the end there is nobody left, who is going to use this tidy new world, then for what?

[hasufell]

e.g. not adding the deprecation message in the first place

How is that an option? No deprecation warning is not an improvement.

You still haven't explained what is going wrong. Are you a -Werror user? Then I'm afraid I don't share sympathy. If you want to turn all warnings into errors, then this is what you get. Silence the warnings you don't need.

re-exposing from os-string,

This is also missing the point of the package split.

you name it

I'm afraid I don't see a viable alternative.

Boot packages have to be able to throw deprecation warnings.

[sol]

e.g. not adding the deprecation message in the first place

How is that an option? No deprecation warning is not an improvement.

It's still better than a deprecation warning, with no sensible action to take.

Are you a -Werror user?

Of course I use -Werror on CI.

Then I'm afraid I don't share sympathy.

I don't need you to share your sympathy. As long as we can avoid pushing opinionated agendas through boot packages, I'm fine.

re-exposing from os-string,

This is also missing the point of the package split.

From a users perspective there is no big harm. I'm not saying it's the only option here, I would be OK with it, I think there are options.

Boot packages have to be able to throw deprecation warnings.

Usually you use deprecation warnings as a precursor of a breaking change. Now, breaking changes themselves are not inevitable or necessary, so "have to" Is possibly a little bit strong here.

I'm not going as far as saying "never deprecate anything", but if you deprecate something and there is no sensible way to address this deprecation warning for half of the users, this is where I see a problem.

[hasufell]

It's still better than a deprecation warning, with no sensible action to take.

I guess we just disagree on that.

As long as we can avoid pushing opinionated agendas through boot packages, I'm fine.

Please refer to haskell/core-libraries-committee#262

I'm not going as far as saying "never deprecate anything", but if you deprecate something and there is no sensible way to address this deprecation warning for half of the users, this is where I see a problem.

Yes, I think this is not ideal, but this requires a proper solution and not core library maintainers to hack around a broken ghc packaging system.

[hasufell]

Of course I use -Werror on CI.

CLC now has unanonimously decided that -Werror users are on their own and that new warnings are not considered breaking changes: haskell/core-libraries-committee#262