Re: Question about Haskell packages

Re: Question about Haskell packages

[Federico Beffa]

Paul van der Walt <paul@denknerd.org> writes:

[...]

> Ah, another question: do you people think it would be worthwhile /
> useful to provide a haskell-platform-$ver metapackage which depends on
> all the exact versions bundled in that HP?  See [1] for a list.

I think it's useful.

Regards,
Fede

Re: Question about Haskell packages

[Federico Beffa]

Paul van der Walt <paul@denknerd.org> writes:

> Hello Guix,
>
> Yesterday i thought to myself that it would be cool to mess around with
> Idris <http://www.idris-lang.org>, on of the dependently-typed
> languages.  Turns out it depends on quite a lot of Hackage packages!  I
> steamed ahead, and now i have packaged all the dependencies.
>
> One weird thing i ran into though, is that frequently, a library L1 will
> build fine, but when you use it as an input to some other library L2,
> the configure phase will fail, saying that L1 is broken, since
> it is missing its dependencies D1..Dn.  Iyzsong suggested on IRC that i
> do like nixpkgs does [0] and simply add all dependencies as
> propagated-inputs.  That should solve that issue, but since i don't 100%
> understand what's going on, i thought it wise to ask you, wise and
> attractive users of Guix, for advice.

The reason is likely that L1 needs one of its input at run time. If
another package declares L1 as its input, but not the library needed by
L1 at run-time, the latter will not be visible in the build environment
(only the declared packages plus some implicit inputs are visible) and
L1 will not be functional. In such a case the library needed at run-time
has to be declared as a propagated-input.

Regards,
Fede

Question about Haskell packages

[Paul van der Walt]

[-- Attachment #1: Type: text/plain, Size: 1395 bytes --]

Hello Guix,

Yesterday i thought to myself that it would be cool to mess around with
Idris <http://www.idris-lang.org>, on of the dependently-typed
languages.  Turns out it depends on quite a lot of Hackage packages!  I
steamed ahead, and now i have packaged all the dependencies.

One weird thing i ran into though, is that frequently, a library L1 will
build fine, but when you use it as an input to some other library L2,
the configure phase will fail, saying that L1 is broken, since
it is missing its dependencies D1..Dn.  Iyzsong suggested on IRC that i
do like nixpkgs does [0] and simply add all dependencies as
propagated-inputs.  That should solve that issue, but since i don't 100%
understand what's going on, i thought it wise to ask you, wise and
attractive users of Guix, for advice.

I will polish the patches before sending them, so don't hold your breath
yet.  I'm currently also trying to upgrade the packages to the Haskell
Platform 7.10.2-a versions.  Turns out GHC is slow to build.

Ah, another question: do you people think it would be worthwhile /
useful to provide a haskell-platform-$ver metapackage which depends on
all the exact versions bundled in that HP?  See [1] for a list.

Thank you for your advice,
p.

0. <https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/haskell-modules/hackage-packages.nix>
1. <https://www.haskell.org/platform/contents.html>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 800 bytes --]

Re: Question about Haskell packages

[Taylan Ulrich Bayırlı/Kammer]

Paul van der Walt <paul@denknerd.org> writes:

> Hello Guix,

Hello!

> Yesterday i thought to myself that it would be cool to mess around with
> Idris <http://www.idris-lang.org>, on of the dependently-typed
> languages.  Turns out it depends on quite a lot of Hackage packages!  I
> steamed ahead, and now i have packaged all the dependencies.
>
> One weird thing i ran into though, is that frequently, a library L1 will
> build fine, but when you use it as an input to some other library L2,
> the configure phase will fail, saying that L1 is broken, since
> it is missing its dependencies D1..Dn.  Iyzsong suggested on IRC that i
> do like nixpkgs does [0] and simply add all dependencies as
> propagated-inputs.  That should solve that issue, but since i don't 100%
> understand what's going on, i thought it wise to ask you, wise and
> attractive users of Guix, for advice.

This sounds very similar to the pkg-config related problems that were
discussed a while back.  (It's a complicated topic, but the thread
starts here if you're interested:
https://lists.gnu.org/archive/html/guix-devel/2015-03/msg00565.html )

Long story short, some systems like pkg-config, and I guess Hackage
(maybe it just uses pkg-config?) aren't smart enough to understand that
a run-time dependency L2 of library L1 might be satisfied without having
any development meta-data of L2 installed during the compilation of a
program P which depends on L1.  Only L1's meta-data is really needed for
program P's compilation, but pkg-config is being "extra smart" and also
checks whether L2's meta-data is present, thinking that if it isn't, it
must mean L1 is broken because it lacks a dependency, as you noted.

(In the case of pkg-config, the meta-data is in "libfoo.pc" files in
$PKG_CONFIG_PATH.)

To work around that, we make L2 a "propagated input" of L1, meaning
whenever L1 is installed in some environment, the whole of L2 is also
installed (rather than making L2 invisible in the environment, although
it's really on the system and L1 refers to it via absolute file names).

Someone with specific knowledge of Hackage might want to confirm whether
it really has the exact same behavior as pkg-config, or whether there's
a better workaround for it.  If it doesn't, then indeed you need to turn
some inputs of L1 into propagated inputs.

Hope that helps,
Taylan