Open sol opened 6 months ago
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: https://github.com/haskell/cabal/issues/9669
So users get overly exposed to filepath versions that are considered obsolete already.
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?
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.
and I asked several people beforehand on how to do a package split.
https://github.com/haskell/core-libraries-committee/issues/221
ghc
depends onfilepath
. Is there a way to depend on bothghc-9.8.2
and importSystem.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:
ghc
depends on filepath
ghc
you can't upgrade filepath
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 https://github.com/haskell/cabal/issues/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 https://github.com/haskell/cabal/issues/9669.
I suspect what's really causing issues is that cabal doesn't handle boot packages well: https://github.com/haskell/cabal/issues/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
.
Apparently, template-haskell
vendors filepath
by now.
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.
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?
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.
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.
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 https://github.com/haskell/core-libraries-committee/issues/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.
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: https://github.com/haskell/core-libraries-committee/issues/262
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:
So yeah, moving stuff into separate packages can make sense. But wait, why doesn't
filepath
just, re-expose that module fromos-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 usePackageImports
and be done with it... oh, wait, WHAAAAAT,filepath
does not even depend onos-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 thoseOPTIONS_GHC
s again...Sounds like a lot of wasted effort to me... for what?