search

haskell / unix

POSIX functionality
https://hackage.haskell.org/package/unix
Other
107 stars 92 forks source link

Support filepath >= 1.5.0.0 and os-string #305

Closed hasufell closed 1 year ago

vdukhovni commented 1 year ago

Under what conditions is the new os-string flag set?

Bodigrim commented 1 year ago

@vdukhovni it's an automatic flag, Cabal solver will figure it out depending on a required build plan.

vdukhovni commented 1 year ago

So like the cabal-syntax flag that's been me grief recently, right? :-)

vdukhovni commented 1 year ago

Should any of the tests insist on the flag being set? Or does that already happen automatically for some of them, based on their extant "build plan"? (By tests here I mean CI runs)

hasufell commented 1 year ago

So like the cabal-syntax flag that's been me grief recently, right? :-)

I've never done this sort of stuff, so I'm not sure about all the consequences.

What exactly caused grief?

hasufell commented 1 year ago

Should any of the tests insist on the flag being set? Or does that already happen automatically for some of them, based on their extant "build plan"? (By tests here I mean CI runs)

Yeah, should probably add that.

Bodigrim commented 1 year ago

What exactly caused grief?

See https://github.com/haskell/cabal/issues/8370.

A downstream package can end up with a build plan containing both filepath-1.4 and os-string-2.0. If it's not careful enough, it easily runs into conflicting identifiers and hard to debug build errors.

That said, I think we are in a better position than hackage-security here: unix is to depend on filepath in both branches, and CPP conditions are in terms of #if MIN_VERSION_filepath(1,5,0) as opposed to #ifdef MIN_VERSION_os_string.

hasufell commented 1 year ago

Yeah, packages that want to work across many GHC versions and use OsString will have to pay a toll.

We may need a better migration guide.

vdukhovni commented 1 year ago

I'm a bit concerned about the flag being inappropriately chosen by the solver, causing issues similar to what I see with older cabal-install builds. Are we sure the ecosystem will handle the flag gracefully?

If the GHC team is on the verge of cutting 9.6.4, I'd actually prefer to not include this change so late in the process of creating a bug-fix GHC release. It should instead appear in a future 9.10.1 release, with lots of previous CI runs.