Haskell dependencies for custom cabal builds

Haskell dependencies for custom cabal builds

[John Soo]

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

Hi Guix,

I’ve been working on some Haskell packages and got stuck recently and I didn’t know why until I realized the cabal files have `build-type: Custom` (http://hackage.haskell.org/package/termonad-1.1.0.0/termonad.cabal). I always get missing dependencies even though I have the dependencies listed in `inputs` (haskell-gi-base and friends in the example above). What do I need to do to fix this?

Thanks!

John

[-- Attachment #2: Type: text/html, Size: 711 bytes --]

Re: Haskell dependencies for custom cabal builds

[Timothy Sample]

Hi John,

John Soo <jsoo1@asu.edu> writes:

> Hi Guix,
>
> I’ve been working on some Haskell packages and got stuck recently and I didn’t know why until I realized the cabal files have `build-type: Custom`
> (http://hackage.haskell.org/package/termonad-1.1.0.0/termonad.cabal). I always get missing dependencies even though I have the dependencies listed in `inputs` (haskell-gi-base and
> friends in the example above). What do I need to do to fix this?

You might be able to take some inspiration from git-annex, which I
believe has the same problem.

In short, the issue is that the haskell-build-system unsets
“GHC_PACKAGE_PATH” before calling “runhaskell Setup.hs”.  This is
because it assumes that “Setup.hs” will use Cabal in a pretty direct
way, and that Cabal will setup the required packages from the command
line (Cabal complains if you try to use “GHC_PACKAGE_PATH”, because it
wants to be in control of the environment).  If the custom build code
needs dependencies, they will not be available (unless it does what
Cabal does and reads package paths from the command line and sets
everything up from within Haskell).

For git-annex, I was able to skirt the problem.  I don’t know how to
solve it.  If you keep “GHC_PACKAGE_PATH” set, the Cabal part of the
build will likely complain.  However, without it, the custom part of the
build can’t find its dependencies.

That’s about all I can recall right now.  I hope that helps at least a
little bit!  :)


-- Tim

Re: Haskell dependencies for custom cabal builds

[John Soo]

Thanks Tim,

I’ll check out git-annex as a start. Custom Cabal builds would be a nice feature to add to the haskell-build-system. Would it be sufficient to add some extra argument to the build system?

Best,

John

> On Feb 11, 2019, at 12:19 PM, Timothy Sample <samplet@ngyro.com> wrote:
> 
> Hi John,
> 
> John Soo <jsoo1@asu.edu> writes:
> 
>> Hi Guix,
>> 
>> I’ve been working on some Haskell packages and got stuck recently and I didn’t know why until I realized the cabal files have `build-type: Custom`
>> (http://hackage.haskell.org/package/termonad-1.1.0.0/termonad.cabal). I always get missing dependencies even though I have the dependencies listed in `inputs` (haskell-gi-base and
>> friends in the example above). What do I need to do to fix this?
> 
> You might be able to take some inspiration from git-annex, which I
> believe has the same problem.
> 
> In short, the issue is that the haskell-build-system unsets
> “GHC_PACKAGE_PATH” before calling “runhaskell Setup.hs”.  This is
> because it assumes that “Setup.hs” will use Cabal in a pretty direct
> way, and that Cabal will setup the required packages from the command
> line (Cabal complains if you try to use “GHC_PACKAGE_PATH”, because it
> wants to be in control of the environment).  If the custom build code
> needs dependencies, they will not be available (unless it does what
> Cabal does and reads package paths from the command line and sets
> everything up from within Haskell).
> 
> For git-annex, I was able to skirt the problem.  I don’t know how to
> solve it.  If you keep “GHC_PACKAGE_PATH” set, the Cabal part of the
> build will likely complain.  However, without it, the custom part of the
> build can’t find its dependencies.
> 
> That’s about all I can recall right now.  I hope that helps at least a
> little bit!  :)
> 
> 
> -- Tim

Re: Haskell dependencies for custom cabal builds

[Timothy Sample]

Hi John,

John Soo <jsoo1@asu.edu> writes:

> I’ll check out git-annex as a start. Custom Cabal builds would be a
> nice feature to add to the haskell-build-system. Would it be
> sufficient to add some extra argument to the build system?

At this point, I don’t know what the argument would do.  :)

The solution I came up with for git-annex only works for git-annex.  I
had to carefully read the build code, and carve out certain parts so
that they could run in different environments.  It is not something that
could be enabled by an argument.

The only idea I have would be switching from using “runhaskell Setup.hs”
to using the “cabal” executable.  Hopefully, Cabal would set up the GHC
package database before running the custom code.  If it worked, it could
be enabled by a build-system argument.  I’m definitely just guessing
here, though.  If you wanted to test this, you could copy out code from
“guix/build/haskell-build-system.scm” into custom phases in your
package.  If it proves useful, we could adapt it into the build system.

So far, custom builds have been extremely rare, so these issues are not
very well explored.


-- Tim

Re: Haskell dependencies for custom cabal builds

[John Soo]

Hi there,

I did a little digging this morning and it seems like runhaskell is probably deprecated in favor of runghc. Do we expect anyone to be using hugs or jhc?  Runghc also supports ghc flags. I still need to do some more research here but the Haskell configure phase deliberately unsets GHC_PACKAGE_PATH. I assume it does this because runhaskell supports many Haskell compilers. If custom cabal builds are rare, I would suspect that non-ghc builds are even rarer. Would it be possible to replace runhaskell with runghc? Or parameterize the command?

Thanks,

John

> On Feb 12, 2019, at 8:06 AM, Timothy Sample <samplet@ngyro.com> wrote:
> 
> Hi John,
> 
> John Soo <jsoo1@asu.edu> writes:
> 
>> I’ll check out git-annex as a start. Custom Cabal builds would be a
>> nice feature to add to the haskell-build-system. Would it be
>> sufficient to add some extra argument to the build system?
> 
> At this point, I don’t know what the argument would do.  :)
> 
> The solution I came up with for git-annex only works for git-annex.  I
> had to carefully read the build code, and carve out certain parts so
> that they could run in different environments.  It is not something that
> could be enabled by an argument.
> 
> The only idea I have would be switching from using “runhaskell Setup.hs”
> to using the “cabal” executable.  Hopefully, Cabal would set up the GHC
> package database before running the custom code.  If it worked, it could
> be enabled by a build-system argument.  I’m definitely just guessing
> here, though.  If you wanted to test this, you could copy out code from
> “guix/build/haskell-build-system.scm” into custom phases in your
> package.  If it proves useful, we could adapt it into the build system.
> 
> So far, custom builds have been extremely rare, so these issues are not
> very well explored.
> 
> 
> -- Tim

Re: Haskell dependencies for custom cabal builds

[Timothy Sample]

Hi John,

John Soo <jsoo1@asu.edu> writes:

> Hi there,
>
> I did a little digging this morning and it seems like runhaskell is
> probably deprecated in favor of runghc. Do we expect anyone to be
> using hugs or jhc?  Runghc also supports ghc flags. I still need to do
> some more research here but the Haskell configure phase deliberately
> unsets GHC_PACKAGE_PATH. I assume it does this because runhaskell
> supports many Haskell compilers. If custom cabal builds are rare, I
> would suspect that non-ghc builds are even rarer. Would it be possible
> to replace runhaskell with runghc? Or parameterize the command?

I don’t see how this would help.

From the build system code,

    Cabal errors if GHC_PACKAGE_PATH is set during 'configure', so unset
    and restore it.

The issue that git-annex has is that it wants to use some packages
before calling into Cabal.  If “GHC_PACKAGE_PATH” is set properly, it
will find the packages, proceed normally until calling Cabal, and then
error because Cabal doesn’t like “GHC_PACKAGE_PATH”.  Cabal wants to
setup the package search path from the command line arguments instead.
On the other hand, if “GHC_PACKAGE_PATH” is not set, Cabal would
theoretically work, but we never get there!  The custom “Setup.hs” code
errors out with missing packages before ever calling Cabal.

I don’t think that switching from “runhaskell” to “runghc” changes that.


-- Tim

Re: Haskell dependencies for custom cabal builds

[Timothy Sample]

Hi John,

John Soo <jsoo1@asu.edu> writes:

> Hi there,
>
> I did a little digging this morning and it seems like runhaskell is
> probably deprecated in favor of runghc. Do we expect anyone to be
> using hugs or jhc?  Runghc also supports ghc flags. I still need to do
> some more research here but the Haskell configure phase deliberately
> unsets GHC_PACKAGE_PATH. I assume it does this because runhaskell
> supports many Haskell compilers. If custom cabal builds are rare, I
> would suspect that non-ghc builds are even rarer. Would it be possible
> to replace runhaskell with runghc? Or parameterize the command?

I don’t see how this would help.

From the build system code,

    Cabal errors if GHC_PACKAGE_PATH is set during 'configure', so unset
    and restore it.

The issue that git-annex has is that it wants to use some packages
before calling into Cabal.  If “GHC_PACKAGE_PATH” is set properly, it
will find the packages, proceed normally until calling Cabal, and then
error because Cabal doesn’t like “GHC_PACKAGE_PATH”.  Cabal wants to
setup the package search path from the command line arguments instead.
On the other hand, if “GHC_PACKAGE_PATH” is not set, Cabal would
theoretically work, but we never get there!  The custom “Setup.hs” code
errors out with missing packages before ever calling Cabal.

I don’t think that switching from “runhaskell” to “runghc” changes that.


-- Tim

Re: Haskell dependencies for custom cabal builds

[John Soo]

Thanks Tim!

Good to know! Thank you. Looking again at the call to runhaskell in the configure phase, then.  It does accept --package-db as an argument. Is it feasible to parse GHC_PACKAGE_PATH into the correct package paths instead of using the environment variable?

Thanks!

John

> On Feb 12, 2019, at 11:21 AM, Timothy Sample <samplet@ngyro.com> wrote:
> 
> Hi John,
> 
> John Soo <jsoo1@asu.edu> writes:
> 
>> Hi there,
>> 
>> I did a little digging this morning and it seems like runhaskell is
>> probably deprecated in favor of runghc. Do we expect anyone to be
>> using hugs or jhc?  Runghc also supports ghc flags. I still need to do
>> some more research here but the Haskell configure phase deliberately
>> unsets GHC_PACKAGE_PATH. I assume it does this because runhaskell
>> supports many Haskell compilers. If custom cabal builds are rare, I
>> would suspect that non-ghc builds are even rarer. Would it be possible
>> to replace runhaskell with runghc? Or parameterize the command?
> 
> I don’t see how this would help.
> 
> From the build system code,
> 
>    Cabal errors if GHC_PACKAGE_PATH is set during 'configure', so unset
>    and restore it.
> 
> The issue that git-annex has is that it wants to use some packages
> before calling into Cabal.  If “GHC_PACKAGE_PATH” is set properly, it
> will find the packages, proceed normally until calling Cabal, and then
> error because Cabal doesn’t like “GHC_PACKAGE_PATH”.  Cabal wants to
> setup the package search path from the command line arguments instead.
> On the other hand, if “GHC_PACKAGE_PATH” is not set, Cabal would
> theoretically work, but we never get there!  The custom “Setup.hs” code
> errors out with missing packages before ever calling Cabal.
> 
> I don’t think that switching from “runhaskell” to “runghc” changes that.
> 
> 
> -- Tim

Re: Haskell dependencies for custom cabal builds

[Marius Bakke]

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

Hello!

Timothy Sample <samplet@ngyro.com> writes:

> Hi John,
>
> John Soo <jsoo1@asu.edu> writes:
>
>> Hi there,
>>
>> I did a little digging this morning and it seems like runhaskell is
>> probably deprecated in favor of runghc. Do we expect anyone to be
>> using hugs or jhc?  Runghc also supports ghc flags. I still need to do
>> some more research here but the Haskell configure phase deliberately
>> unsets GHC_PACKAGE_PATH. I assume it does this because runhaskell
>> supports many Haskell compilers. If custom cabal builds are rare, I
>> would suspect that non-ghc builds are even rarer. Would it be possible
>> to replace runhaskell with runghc? Or parameterize the command?
>
> I don’t see how this would help.
>
> From the build system code,
>
>     Cabal errors if GHC_PACKAGE_PATH is set during 'configure', so unset
>     and restore it.
>
> The issue that git-annex has is that it wants to use some packages
> before calling into Cabal.  If “GHC_PACKAGE_PATH” is set properly, it
> will find the packages, proceed normally until calling Cabal, and then
> error because Cabal doesn’t like “GHC_PACKAGE_PATH”.  Cabal wants to
> setup the package search path from the command line arguments instead.
> On the other hand, if “GHC_PACKAGE_PATH” is not set, Cabal would
> theoretically work, but we never get there!  The custom “Setup.hs” code
> errors out with missing packages before ever calling Cabal.

FWIW here is the upstream issue:

<https://github.com/haskell/cabal/issues/3728>

Note that it was "fixed" briefly by these commits:

<https://github.com/haskell/cabal/pull/3753>

Unfortunately it was later reverted due to breaking some edge(?) cases,
and a Nix-specific workaround that I don't really understand was merged:

<https://github.com/haskell/cabal/pull/4193>

I wonder if we should try picking the original Cabal fix from ttuegel,
maybe as a separate package if it really is a breaking change.  Thoughts?

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

Re: Haskell dependencies for custom cabal builds

[John Soo]

Thanks Marius,

I’m feeling quite out of my depth here so thanks for the background. It seems like maintaining a fork effectively might be a lot more work. Is there really no other good way to accomplish a custom build?

John

> On Feb 12, 2019, at 11:44 AM, Marius Bakke <mbakke@fastmail.com> wrote:
> 
> Hello!
> 
> Timothy Sample <samplet@ngyro.com> writes:
> 
>> Hi John,
>> 
>> John Soo <jsoo1@asu.edu> writes:
>> 
>>> Hi there,
>>> 
>>> I did a little digging this morning and it seems like runhaskell is
>>> probably deprecated in favor of runghc. Do we expect anyone to be
>>> using hugs or jhc?  Runghc also supports ghc flags. I still need to do
>>> some more research here but the Haskell configure phase deliberately
>>> unsets GHC_PACKAGE_PATH. I assume it does this because runhaskell
>>> supports many Haskell compilers. If custom cabal builds are rare, I
>>> would suspect that non-ghc builds are even rarer. Would it be possible
>>> to replace runhaskell with runghc? Or parameterize the command?
>> 
>> I don’t see how this would help.
>> 
>> From the build system code,
>> 
>>    Cabal errors if GHC_PACKAGE_PATH is set during 'configure', so unset
>>    and restore it.
>> 
>> The issue that git-annex has is that it wants to use some packages
>> before calling into Cabal.  If “GHC_PACKAGE_PATH” is set properly, it
>> will find the packages, proceed normally until calling Cabal, and then
>> error because Cabal doesn’t like “GHC_PACKAGE_PATH”.  Cabal wants to
>> setup the package search path from the command line arguments instead.
>> On the other hand, if “GHC_PACKAGE_PATH” is not set, Cabal would
>> theoretically work, but we never get there!  The custom “Setup.hs” code
>> errors out with missing packages before ever calling Cabal.
> 
> FWIW here is the upstream issue:
> 
> <https://github.com/haskell/cabal/issues/3728>
> 
> Note that it was "fixed" briefly by these commits:
> 
> <https://github.com/haskell/cabal/pull/3753>
> 
> Unfortunately it was later reverted due to breaking some edge(?) cases,
> and a Nix-specific workaround that I don't really understand was merged:
> 
> <https://github.com/haskell/cabal/pull/4193>
> 
> I wonder if we should try picking the original Cabal fix from ttuegel,
> maybe as a separate package if it really is a breaking change.  Thoughts?