propagating inputs in ghc-* packages

propagating inputs in ghc-* packages

[Federico Beffa]

Ricardo Wurmus <rekado@elephly.net> writes:

> Hi Guix,
>
> I’m in the middle of upgrading our Haskell packages.  (Actually, I’m
> just yak shaving.  I need “pandoc-citeproc” for “r-knitr”…)
>
> I noticed that upgrading Haskell packages is a pain in the neck because
> of propagated inputs.  It seems that not all packages have fully
> declared dependencies and just work accidentally because of propagated
> inputs of a related package.  This also makes upgrades more difficult
> because I can get substitutes from Hydra that depend on older versions
> of some Haskell packages.
>
> It looks like Haskell binaries actually embed references to other
> Haskell packages, so I’m not sure we actually need to propagate anything
> at all.  Could someone please confirm this?

From what I recall, binary executables include references to packages,
but libraries do not.  So, at least at the time I wrote the first
version of the haskell-build-system, propagated inputs seemed to be
necessary for packages providing libraries, but not for ones providing
applications.

Regards,
Fede

Re: propagating inputs in ghc-* packages

[Ricardo Wurmus]

Federico Beffa <beffa@ieee.org> writes:

> Ricardo Wurmus <rekado@elephly.net> writes:
>
>> Hi Guix,
>>
>> I’m in the middle of upgrading our Haskell packages.  (Actually, I’m
>> just yak shaving.  I need “pandoc-citeproc” for “r-knitr”…)
>>
>> I noticed that upgrading Haskell packages is a pain in the neck because
>> of propagated inputs.  It seems that not all packages have fully
>> declared dependencies and just work accidentally because of propagated
>> inputs of a related package.  This also makes upgrades more difficult
>> because I can get substitutes from Hydra that depend on older versions
>> of some Haskell packages.
>>
>> It looks like Haskell binaries actually embed references to other
>> Haskell packages, so I’m not sure we actually need to propagate anything
>> at all.  Could someone please confirm this?
>
> From what I recall, binary executables include references to packages,
> but libraries do not.  So, at least at the time I wrote the first
> version of the haskell-build-system, propagated inputs seemed to be
> necessary for packages providing libraries, but not for ones providing
> applications.

Thanks for this comment.  With Eric Bavier’s patch this seems no longer
necessary.  I’ve already rebuilt a lot of Haskell packages without any
propagation (and some added inputs), and I’ve got working libraries and
executables.  I’m still rebuilding remaining Haskell packages but I’m
now convinced that propagation is no longer needed with the current
version of the build system.

I’m preparing a patch to remove propagation from all Haskell packages.
Now the question is only whether to do this all in one patch or in one
patch per package… :)

~~ Ricardo

Re: propagating inputs in ghc-* packages

[Federico Beffa]

>> Ricardo Wurmus <rekado@elephly.net> writes:
>>
>>> Hi Guix,
>>>
>>> I’m in the middle of upgrading our Haskell packages.  (Actually, I’m
>>> just yak shaving.  I need “pandoc-citeproc” for “r-knitr”…)
>>>
>>> I noticed that upgrading Haskell packages is a pain in the neck because
>>> of propagated inputs.  It seems that not all packages have fully
>>> declared dependencies and just work accidentally because of propagated
>>> inputs of a related package.  This also makes upgrades more difficult
>>> because I can get substitutes from Hydra that depend on older versions
>>> of some Haskell packages.
>>>
>>> It looks like Haskell binaries actually embed references to other
>>> Haskell packages, so I’m not sure we actually need to propagate anything
>>> at all.  Could someone please confirm this?
>>
>> From what I recall, binary executables include references to packages,
>> but libraries do not.  So, at least at the time I wrote the first
>> version of the haskell-build-system, propagated inputs seemed to be
>> necessary for packages providing libraries, but not for ones providing
>> applications.
>
> Thanks for this comment.  With Eric Bavier’s patch this seems no longer
> necessary.  I’ve already rebuilt a lot of Haskell packages without any
> propagation (and some added inputs), and I’ve got working libraries and
> executables.  I’m still rebuilding remaining Haskell packages but I’m
> now convinced that propagation is no longer needed with the current
> version of the build system.
>
> I’m preparing a patch to remove propagation from all Haskell packages.
> Now the question is only whether to do this all in one patch or in one
> patch per package… :)

That sounds great! Just to be sure: you are saying that if you install
any library (call it A) and the GHC compiler into your profile then you
are able to compile your program (making use of library A) without
also having to manually install any input of library A?

Regards,
Fede

Re: propagating inputs in ghc-* packages

[Ricardo Wurmus]

Federico Beffa <beffa@ieee.org> writes:

>>> Ricardo Wurmus <rekado@elephly.net> writes:
>>>
>>>> Hi Guix,
>>>>
>>>> I’m in the middle of upgrading our Haskell packages.  (Actually, I’m
>>>> just yak shaving.  I need “pandoc-citeproc” for “r-knitr”…)
>>>>
>>>> I noticed that upgrading Haskell packages is a pain in the neck because
>>>> of propagated inputs.  It seems that not all packages have fully
>>>> declared dependencies and just work accidentally because of propagated
>>>> inputs of a related package.  This also makes upgrades more difficult
>>>> because I can get substitutes from Hydra that depend on older versions
>>>> of some Haskell packages.
>>>>
>>>> It looks like Haskell binaries actually embed references to other
>>>> Haskell packages, so I’m not sure we actually need to propagate anything
>>>> at all.  Could someone please confirm this?
>>>
>>> From what I recall, binary executables include references to packages,
>>> but libraries do not.  So, at least at the time I wrote the first
>>> version of the haskell-build-system, propagated inputs seemed to be
>>> necessary for packages providing libraries, but not for ones providing
>>> applications.
>>
>> Thanks for this comment.  With Eric Bavier’s patch this seems no longer
>> necessary.  I’ve already rebuilt a lot of Haskell packages without any
>> propagation (and some added inputs), and I’ve got working libraries and
>> executables.  I’m still rebuilding remaining Haskell packages but I’m
>> now convinced that propagation is no longer needed with the current
>> version of the build system.
>>
>> I’m preparing a patch to remove propagation from all Haskell packages.
>> Now the question is only whether to do this all in one patch or in one
>> patch per package… :)
>
> That sounds great! Just to be sure: you are saying that if you install
> any library (call it A) and the GHC compiler into your profile then you
> are able to compile your program (making use of library A) without
> also having to manually install any input of library A?

This seems to be the case.  Here is an example ghci session in which I’m
using “ghc-pandoc” as a library without having to install any of the
numerous inputs to “ghc-pandoc” (and their inputs):

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./pre-inst-env guix environment --ad-hoc ghc ghc-pandoc
[…]
rekado in guix-wip [env]: ghci
GHCi, version 7.10.2: http://www.haskell.org/ghc/  :? for help
Prelude> import Text.Pandoc
Prelude Text.Pandoc> readMarkdown def "Hello"
Right (Pandoc (Meta {unMeta = fromList []}) [Para [Str "Hello"]])
Prelude Text.Pandoc> :q
Leaving GHCi.
rekado in guix-wip [env]:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This looks good to me.  Did I misunderstand your query?

~~ Ricardo

Re: propagating inputs in ghc-* packages

[Federico Beffa]

On Sun, Oct 2, 2016 at 6:21 AM, Ricardo Wurmus <rekado@elephly.net> wrote:
>> That sounds great! Just to be sure: you are saying that if you install
>> any library (call it A) and the GHC compiler into your profile then you
>> are able to compile your program (making use of library A) without
>> also having to manually install any input of library A?
>
> This seems to be the case.  Here is an example ghci session in which I’m
> using “ghc-pandoc” as a library without having to install any of the
> numerous inputs to “ghc-pandoc” (and their inputs):
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ./pre-inst-env guix environment --ad-hoc ghc ghc-pandoc
> […]
> rekado in guix-wip [env]: ghci
> GHCi, version 7.10.2: http://www.haskell.org/ghc/  :? for help
> Prelude> import Text.Pandoc
> Prelude Text.Pandoc> readMarkdown def "Hello"
> Right (Pandoc (Meta {unMeta = fromList []}) [Para [Str "Hello"]])
> Prelude Text.Pandoc> :q
> Leaving GHCi.
> rekado in guix-wip [env]:
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Nice. Thanks for checking.

Re: propagating inputs in ghc-* packages

[Leo Famulari]

On Sat, Oct 01, 2016 at 09:45:21AM +0200, Ricardo Wurmus wrote:
> I’m preparing a patch to remove propagation from all Haskell packages.
> Now the question is only whether to do this all in one patch or in one
> patch per package… :)

I'd say whichever method is easiest :) And then we can test it with
Hydra on a ghc-updates branch.

propagating inputs in ghc-* packages

[Ricardo Wurmus]

Hi Guix,

I’m in the middle of upgrading our Haskell packages.  (Actually, I’m
just yak shaving.  I need “pandoc-citeproc” for “r-knitr”…)

I noticed that upgrading Haskell packages is a pain in the neck because
of propagated inputs.  It seems that not all packages have fully
declared dependencies and just work accidentally because of propagated
inputs of a related package.  This also makes upgrades more difficult
because I can get substitutes from Hydra that depend on older versions
of some Haskell packages.

It looks like Haskell binaries actually embed references to other
Haskell packages, so I’m not sure we actually need to propagate anything
at all.  Could someone please confirm this?

~~ Ricardo

Re: propagating inputs in ghc-* packages

[Eric Bavier]

Hello Ricardo,

On 2016-09-30 04:24, Ricardo Wurmus wrote:
> Hi Guix,
> 
> I’m in the middle of upgrading our Haskell packages.  (Actually, I’m
> just yak shaving.  I need “pandoc-citeproc” for “r-knitr”…)
> 
> I noticed that upgrading Haskell packages is a pain in the neck because
> of propagated inputs.  It seems that not all packages have fully
> declared dependencies and just work accidentally because of propagated
> inputs of a related package.  This also makes upgrades more difficult
> because I can get substitutes from Hydra that depend on older versions
> of some Haskell packages.
> 
> It looks like Haskell binaries actually embed references to other
> Haskell packages, so I’m not sure we actually need to propagate 
> anything
> at all.  Could someone please confirm this?

Commit e17d513381296b (from almost a year ago!) was intended to allow us 
to remove propagated inputs from our ghc-* packages.  But I didn't 
follow-up at the time, for reasons I forget now, in actually 
un-propagating those inputs.  So if you want to try to do that, it might 
just work.

-- 
`~Eric

Re: propagating inputs in ghc-* packages

[Ricardo Wurmus]

Eric Bavier <ericbavier@openmailbox.org> writes:

> Hello Ricardo,
>
> On 2016-09-30 04:24, Ricardo Wurmus wrote:
>> Hi Guix,
>> 
>> I’m in the middle of upgrading our Haskell packages.  (Actually, I’m
>> just yak shaving.  I need “pandoc-citeproc” for “r-knitr”…)
>> 
>> I noticed that upgrading Haskell packages is a pain in the neck because
>> of propagated inputs.  It seems that not all packages have fully
>> declared dependencies and just work accidentally because of propagated
>> inputs of a related package.  This also makes upgrades more difficult
>> because I can get substitutes from Hydra that depend on older versions
>> of some Haskell packages.
>> 
>> It looks like Haskell binaries actually embed references to other
>> Haskell packages, so I’m not sure we actually need to propagate 
>> anything
>> at all.  Could someone please confirm this?
>
> Commit e17d513381296b (from almost a year ago!) was intended to allow us 
> to remove propagated inputs from our ghc-* packages.  But I didn't 
> follow-up at the time, for reasons I forget now, in actually 
> un-propagating those inputs.  So if you want to try to do that, it might 
> just work.

Thank you!  That’s excellent.

Commit 2d47cee25b8bb31d22e6803f1cb3e1679641e14a removes all propagation
from haskell.scm.  I rebuilt all packages and tested that things still
work using “ghc-pandoc” both as an executable and as a library.

~~ Ricardo