Proposal for removing transformers dependency

Alexander V Vershilov alexander.vershilov at gmail.com
Thu Jan 22 08:36:18 UTC 2015


On 22 January 2015 at 10:37, Herbert Valerio Riedel <hvriedel at gmail.com> wrote:
> On 2015-01-21 at 17:19:42 +0100, Alexander V Vershilov wrote:
>> I thought about providing package ghc-transformers-instances, that will
>> provide instances for transformers's type classes for user. So
>> ghc-tf-instances will depend on current ghc, and current transformers that
>> could be provided by user environment.
>
> So the price is seems to be mostly to tolerate orphan instances (and
> potentially having to copy more code from transformers into ghc, if one
> wants to use more features in ghc's code).

Yes, if I didn't miss any other relevant issue.
It's possible that we will need some coercion between Strict State
that comes with GHC and one that is in transformers.

> One would have to make sure to keep that package updated everytime a new
> transformers or ghc package version is released, as well as making sure
> to always test all supported combinations of ghc/transformers versions
> before making a new releases.
>
> One thing to keep in mind though is that then 'haskeline' (which is
> needed by GHCi) still remains a consumer of 'transformers', so we'd
> still have to bundle a 'transformers' package version with GHC even if
> `ghc` doesn't depend on it anymore. Somewhat related, the `ghc` ->
> `Cabal` dependency was broken up in GHC 7.10 but we'll still bundle
> `Cabal` with GHC 7.10.

>From a distro-developer perspective (gentoo) the only relevant library
is ghc library,
and ghc-bin is an executable, so in the worst case user will end up with
having 2 different transformers package. But there will be no transformers
madness as no library pulls concrete version.

> I'm not sure how much this helps Stackage which I assume would
> constraint transformers to a single version, and therefore force a
> reinstall of the haskeline version shipped with GHC with a different
> version of transformers.

I don't know about a Stackage but at least Gentoo allow to install additional
version for packages that are shipped with ghc and ghc library do not
depend on it,
it also handles a case when versions are equal, and then installation is a noop.

Thinking of  haskeline user will have problems only in case if user's haskeline
version is equal to shipped with GHC but depends on a different tf version.
I think that in this case force installing will lead to some level of breakage,
however all executables (ghc-bin) and new libraries will continue working.
Workaround is to make a minor version bump in haskeline and this can be
done purely on a distro-level.

> Fwiw, I welcome decoupling libraries from the GHC distribution as every
> exposed library adds to the synchronisation-with-upstream-overhead when
> preparing new GHC releases, in addition to adding implicit version
> constraints to the package database.
>
> With a GHC release-management hat on though: As for GHC 7.10.1, it's
> rather late... at the very least it needs to get into RC2 (whose cut off
> is tomorrow) for that to happen.

Great. I'll try to cleanup code, and prepare ghc-tf-instances today, test of
the packages that depend on the ghc library in order to understand if
ghc-tf-instances solution works and then send diff to a Phab.

Every tips, suggestions, or reminders of things that I should check will
be gladly accepter.

> Cheers,
>   hvr

-- 
Alexander


More information about the ghc-devs mailing list