incorrect dependencies on template-haskell

[Brandon Moore-2]

template-haskell-2.6.0.0 has inaccurate dependencies thatlead cabal-install to attempt to install it on 6.12.3

The .cabal specifies

    build-depends: base >= 4.2 && < 5,


but assumes TypeSynonymInstances in PprLib.hs

(only true by default after Haskell2010 became default in ghc-7.0.1),

instance Show Doc


and PPr.lhs


import GHC.Show( showMultiLineString )
(added in commit e8d11b1, labeled 4.3.0.0)

It seems the dependency should be at least base >= 4.3,
and either the LANGUAGE pragma or cabal file updated.


If the package isn't meant to be upgraded, should it be on
hackage at all?

Brandon


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

[Antoine Latter-2]

On Sun, Oct 2, 2011 at 8:31 PM, Brandon Moore <[hidden email]> wrote:

> template-haskell-2.6.0.0 has inaccurate dependencies thatlead cabal-install to attempt to install it on 6.12.3
>
> The .cabal specifies
>
>     build-depends: base >= 4.2 && < 5,
>
>
> but assumes TypeSynonymInstances in PprLib.hs
>
> (only true by default after Haskell2010 became default in ghc-7.0.1),
>
> instance Show Doc
>
>
> and PPr.lhs
>
>
> import GHC.Show( showMultiLineString )
> (added in commit e8d11b1, labeled 4.3.0.0)
>
> It seems the dependency should be at least base >= 4.3,
> and either the LANGUAGE pragma or cabal file updated.
>
>
> If the package isn't meant to be upgraded, should it be on
> hackage at all?
>

Using an install of the template-haskell library other than the one
GHC was built against will make GHC unhappy - the operations in the
library won't type-check against the built-in GHC magic.

> Brandon
>
>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/libraries
>

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

[Brandon Moore-2]

> From: Antoine Latter <[hidden email]>

> Sent: Sunday, October 2, 2011 9:21 PM
>
> On Sun, Oct 2, 2011 at 8:31 PM, Brandon Moore <[hidden email]>
> wrote:
...
>>  If the package isn't meant to be upgraded, should it be on
>>  hackage at all?
>>
>
> Using an install of the template-haskell library other than the one
> GHC was built against will make GHC unhappy - the operations in the
> library won't type-check against the built-in GHC magic.

If so, the package should not be on hackage with dependencies that lead
cabal-install to try to upgrade it. I see three ways to fix this

  1) Remove template-haskell from the package index (perhaps keeping
      the documentation somehow)
  2) Strengthen the dependencies enough to force the GHC version
  3) Fix cabal-install to avoid the package.

I don't understand the situation well enough yet, but #1 sounds good
if the package is just on hackage for documentation links, and the set of
libraries tied to a specific compiler is the same for past ghc versions and
other compillers.

Brandon


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

[Ivan Lazar Miljenovic]

On 4 October 2011 05:47, Brandon Moore <[hidden email]> wrote:

>> From: Antoine Latter <[hidden email]>
>
>> Sent: Sunday, October 2, 2011 9:21 PM
>>
>> On Sun, Oct 2, 2011 at 8:31 PM, Brandon Moore <[hidden email]>
>> wrote:
> ...
>>>  If the package isn't meant to be upgraded, should it be on
>>>  hackage at all?
>>>
>>
>> Using an install of the template-haskell library other than the one
>> GHC was built against will make GHC unhappy - the operations in the
>> library won't type-check against the built-in GHC magic.

I see two possible reasons for having it (along with other boot
libraries) still on Hackage:

1) An archive of previous versions

2) In case some other compiler one day supports TH.

> If so, the package should not be on hackage with dependencies that lead
> cabal-install to try to upgrade it. I see three ways to fix this
>
> [snip]
>
>   3) Fix cabal-install to avoid the package.

If ghc-pkg has a notion of "this is a boot library, don't upgrade me!"
I think this is a viable option; it may also make it easier for distro
packagers to be able to determine deps.

--
Ivan Lazar Miljenovic
[hidden email]
IvanMiljenovic.wordpress.com

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

[Brandon Moore-2]

> From: Ivan Lazar Miljenovic <[hidden email]>


...

> I see two possible reasons for having it (along with other boot
> libraries) still on Hackage:
>
> 1) An archive of previous versions

Archiving the packages is good, and especially making to
documentation available for other packages to link into.

It seems this would still be covered if everything else was left how it is,
but the .cabal file for the packages were removed from the package index in
00-index.tgz. Having found

http://hackage.haskell.org/trac/hackage/wiki/HackageDB

I'll see whether that's as easily done as said.

> 2) In case some other compiler one day supports TH.

I don't know of any concrete projects along those lines,
so this doesn't seem to argue for anything beyond point 1).
I suppose another project probably would want to share
the template haskell source, but I expect it would end up
being part of their equivalent of boot libraries.

Brandon


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries