unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
* propagating inputs in ghc-* packages
@ 2016-09-30  9:24 Ricardo Wurmus
  2016-09-30 14:37 ` Eric Bavier
  0 siblings, 1 reply; 9+ messages in thread
From: Ricardo Wurmus @ 2016-09-30  9:24 UTC (permalink / raw)
  To: guix-devel

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: propagating inputs in ghc-* packages
  2016-09-30  9:24 Ricardo Wurmus
@ 2016-09-30 14:37 ` Eric Bavier
  2016-10-02 11:59   ` Ricardo Wurmus
  0 siblings, 1 reply; 9+ messages in thread
From: Eric Bavier @ 2016-09-30 14:37 UTC (permalink / raw)
  To: Ricardo Wurmus; +Cc: guix-devel, Guix-devel

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* propagating inputs in ghc-* packages
@ 2016-09-30 21:07 Federico Beffa
  2016-10-01  7:45 ` Ricardo Wurmus
  0 siblings, 1 reply; 9+ messages in thread
From: Federico Beffa @ 2016-09-30 21:07 UTC (permalink / raw)
  To: rekado; +Cc: Guix-devel

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: propagating inputs in ghc-* packages
  2016-09-30 21:07 propagating inputs in ghc-* packages Federico Beffa
@ 2016-10-01  7:45 ` Ricardo Wurmus
  2016-10-01  9:14   ` Federico Beffa
  2016-10-01 16:31   ` Leo Famulari
  0 siblings, 2 replies; 9+ messages in thread
From: Ricardo Wurmus @ 2016-10-01  7:45 UTC (permalink / raw)
  To: Federico Beffa; +Cc: Guix-devel


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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: propagating inputs in ghc-* packages
  2016-10-01  7:45 ` Ricardo Wurmus
@ 2016-10-01  9:14   ` Federico Beffa
  2016-10-02  4:21     ` Ricardo Wurmus
  2016-10-01 16:31   ` Leo Famulari
  1 sibling, 1 reply; 9+ messages in thread
From: Federico Beffa @ 2016-10-01  9:14 UTC (permalink / raw)
  To: Ricardo Wurmus; +Cc: Guix-devel

>> 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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: propagating inputs in ghc-* packages
  2016-10-01  7:45 ` Ricardo Wurmus
  2016-10-01  9:14   ` Federico Beffa
@ 2016-10-01 16:31   ` Leo Famulari
  1 sibling, 0 replies; 9+ messages in thread
From: Leo Famulari @ 2016-10-01 16:31 UTC (permalink / raw)
  To: Ricardo Wurmus; +Cc: Guix-devel, Federico Beffa

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.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: propagating inputs in ghc-* packages
  2016-10-01  9:14   ` Federico Beffa
@ 2016-10-02  4:21     ` Ricardo Wurmus
  2016-10-02 15:42       ` Federico Beffa
  0 siblings, 1 reply; 9+ messages in thread
From: Ricardo Wurmus @ 2016-10-02  4:21 UTC (permalink / raw)
  To: Federico Beffa; +Cc: Guix-devel


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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: propagating inputs in ghc-* packages
  2016-09-30 14:37 ` Eric Bavier
@ 2016-10-02 11:59   ` Ricardo Wurmus
  0 siblings, 0 replies; 9+ messages in thread
From: Ricardo Wurmus @ 2016-10-02 11:59 UTC (permalink / raw)
  To: Eric Bavier; +Cc: guix-devel, Guix-devel


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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: propagating inputs in ghc-* packages
  2016-10-02  4:21     ` Ricardo Wurmus
@ 2016-10-02 15:42       ` Federico Beffa
  0 siblings, 0 replies; 9+ messages in thread
From: Federico Beffa @ 2016-10-02 15:42 UTC (permalink / raw)
  To: Ricardo Wurmus; +Cc: Guix-devel

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.

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2016-10-02 16:13 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-09-30 21:07 propagating inputs in ghc-* packages Federico Beffa
2016-10-01  7:45 ` Ricardo Wurmus
2016-10-01  9:14   ` Federico Beffa
2016-10-02  4:21     ` Ricardo Wurmus
2016-10-02 15:42       ` Federico Beffa
2016-10-01 16:31   ` Leo Famulari
  -- strict thread matches above, loose matches on Subject: below --
2016-09-30  9:24 Ricardo Wurmus
2016-09-30 14:37 ` Eric Bavier
2016-10-02 11:59   ` Ricardo Wurmus

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).