[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: heads-up: Haskell updates
From: |
Timothy Sample |
Subject: |
Re: heads-up: Haskell updates |
Date: |
Thu, 15 Feb 2018 09:02:43 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) |
Ricardo Wurmus <address@hidden> writes:
> I think that’s a misunderstanding. The cause for the error is earlier
> when it complains that some packages depend on different versions of the
> “transformers” package. “StateT” is a monad transformer.
For what it’s worth, I fixed this error on my machine by adding
“ghc-transformers” as an input to “ghc-transformers-compat”. (This also
fixed “ghc-adjunctions”.) This suggests to me that what you wrote
earlier accounts for the problem:
> * many problems are caused by the fact that GHC includes a bunch of
> packages that really shouldn’t be overridden by packages. Examples
> are ghc-directory, ghc-binary, ghc-bytestring, etc. Since we still
> have packages where these inputs are used, there can be conflicts down
> the line, which are hard to fix.
The “ghc-transformers-compat” package was using “transformers” from GHC,
while “resourcet” and “adjunctions” used our “ghc-transformers” package
from Hackage. Forcing “ghc-transformers-compat” to also use
“transformers” from Hackage fixes the problems.
I was trying to see if I could get Idris to build, and after fixing
these two packages, ran into similar problems with “ghc-binary”.
It looks like we might need some kind of policy here. Either we don’t
tinker with (override) the built-in GHC packages or we somehow hide them
during builds. If we decided not to override them, we should consider
deleting all the packages that do so. Then all the dependent packages
would pick up their dependencies from GHC (somewhat implicitly). If we
hid the built-in packages, it would require that every Haskell package
be explicit about which built-in GHC packages it uses (which is not
currently the case as demonstrated above).
Both of these approaches would probably cause a lot of errors right off
the start. The first approach would cause compile-time errors
(references to undefined variables in Guile), and the second, build
errors.
Unfortunately, I don’t know enough about Haskell to comment on whether
or not these packages “really shouldn’t be overridden” or not. (It
makes sense to me, but OTOH, why are they all split up and on Hackage if
not for tinkering?) If they really shouldn’t be overridden, then we
should stop doing so!
I’m happy to work on this if there is a path forward.
Thoughts?
-- Tim
- Re: heads-up: Haskell updates, (continued)
- Re: heads-up: Haskell updates, Ricardo Wurmus, 2018/02/15
- Re: heads-up: Haskell updates, Ricardo Wurmus, 2018/02/14
- Re: heads-up: Haskell updates, Ricardo Wurmus, 2018/02/14
- Re: heads-up: Haskell updates, Mark H Weaver, 2018/02/14
- Re: heads-up: Haskell updates, Andreas Enge, 2018/02/14
- Re: heads-up: Haskell updates, Ricardo Wurmus, 2018/02/14
- Re: heads-up: Haskell updates, Danny Milosavljevic, 2018/02/14
- Re: heads-up: Haskell updates, Mark H Weaver, 2018/02/15
- Re: heads-up: Haskell updates, Ricardo Wurmus, 2018/02/15
- Re: heads-up: Haskell updates, Mark H Weaver, 2018/02/15
- Re: heads-up: Haskell updates,
Timothy Sample <=
- Re: heads-up: Haskell updates, Ricardo Wurmus, 2018/02/15
- Re: heads-up: Haskell updates, Ricardo Wurmus, 2018/02/17
- Re: heads-up: Haskell updates, Ricardo Wurmus, 2018/02/17
- Re: heads-up: Haskell updates, Andreas Enge, 2018/02/17
- Re: heads-up: Haskell updates, Ricardo Wurmus, 2018/02/17
- Re: heads-up: Haskell updates, Mark H Weaver, 2018/02/17
- core-updates, last call?, Leo Famulari, 2018/02/17
- Re: core-updates, last call?, Ricardo Wurmus, 2018/02/17
- Re: core-updates, last call?, Pjotr Prins, 2018/02/18
- Re: core-updates, last call?, Ricardo Wurmus, 2018/02/18