On 22 January 2015 at 10:37, Herbert Valerio Riedel
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