haskell-fay haskell-fayBase

[manpages]

Greetings, people. I'm trying to move all of my Haskell-related development to Nix and get the following both on NixOS and running nix on Arch Linux (providing a clean output of commands in a clean vm for purity, hehe):

[guest@nixvm:~]$ nix-channel --list

[guest@nixvm:~]$ nix-channel --add http://nixos.org/channels/nixpkgs-unstable

[guest@nixvm:~]$ nix-channel --update
downloading Nix expressions from `http://releases.nixos.org/nixpkgs/nixpkgs-14.04pre42122.e572b5c/nixexprs.tar.xz'...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 4247k  100 4247k    0     0   931k      0  0:00:04  0:00:04 --:--:--  931k
unpacking channels...
created 2 symlinks in user environment

[guest@nixvm:~]$ nix-env -iA nixpkgs.haskellPackages.fay
warning: name collision in input Nix expressions, skipping `/home/guest/.nix-defexpr/channels_root/nixpkgs'
installing `haskell-fay-ghc7.6.3-0.19.2'
building path(s) `/nix/store/a8qa3zflcslsvvjh35gf0ppc27q820h2-user-environment'
created 298 symlinks in user environment

[guest@nixvm:~]$ nix-env -iA nixpkgs.haskellPackages.fayBase
warning: name collision in input Nix expressions, skipping `/home/guest/.nix-defexpr/channels_root/nixpkgs'
installing `haskell-fay-base-ghc7.6.3-0.19.1.1'
building path(s) `/nix/store/zlq76i5vgmxi8wzhi16ai1hvv9swlj31-user-environment'
created 303 symlinks in user environment

[guest@nixvm:~]$ fay Test.hs 
fay: unable to find (existing) package's share dir: fay-base
tried: /nix/store/ic399x6sz939sgm9qxf03yln4psfrqrr-haskell-fay-ghc7.6.3-0.19.2/share/fay-base-0.19.1.1
/nix/store/ic399x6sz939sgm9qxf03yln4psfrqrr-haskell-fay-ghc7.6.3-0.19.2/share/fay-base-0.19.1.1/src

but none of them seem to have Haskell files in them.
If you are using a sandbox you need to specify the HASKELL_PACKAGE_SANDBOX environment variable or use --package-conf.

Am I missing something?

[ocharles]

It looks like fay doesn't know where to look for fay-base - it's only searching in the fay installation directory. Maybe it's worth dragging in @bergmark and the rest of those smart Fay folks to see if they have any suggestions :)

[manpages]

@ocharles well, I can't see a particularly good reason for fay-base and fay being different entities to begin with. I kinda understand the idea behind moving fay-jquery and other non-essential stuff to a different hackage package but not these two, maybe @bergmark will shed some light on this (we're summoning him here, is that correct? :) ).

I think for now I'll just wrap fay into a new hackage project and nix it in my dev environment like this.

[bergmark]

The reason they are separate packages is because if you write a fay package and put fay in your build-depends you will pull in the dependency on base which will cause name clashes with fay's Prelude etc when type checking.

We use a heuristic (ie. ugly hack) to determine where fay package sources are located based on fay's installation directory. This works for standard cabal setups but a lot of distros trying to re-package fay has had this problem. We can't solve this by using Paths modules since fay would then need a reverse dependency on all fay packages.

Is this a new problem for nix? This part of Fay hasn't changed since we split out fay-base over a year ago so either it's always been broken or there has been some change in where nix installs things.

Passing --package-conf probably won't help, but using --base-path might.

This might improve with Cabal 1.20, but for now either use --base-path or patch fay so you can configure a custom resolvePackage function.

[peti]

Do I understand that correctly: The build of haskell-fay needs --base-path=${fayBase} passed at configure time? If that's the case, then I can make the necessary change in cabal2nix.

[bergmark]

I'm not sure what you mean by "configure time". It needs to be passed when you invoke the fay executable, fay --base-path /foo/cabal/share/fay-base Hello.hs where that path points to the share directory of fay-base where src/Prelude.hs and friends are located.

[peti]

I thought that there might be a way to compile fay in such a way that it knows the correct path to its base library, but apparently fay doesn't support that. :-(

In that case, the only way to solve this issue is to create a wrapper for the fay binary that specifies the correct --base-path option on the command line. It would be really nice of upstream could fix their path logic instead.

[bergmark]

Hmm maybe that option could be added. Is the share directory for haskell packages known before they are installed on nix?

[bergmark]

If that's tricky (sounds hacky anyway) you may consider (perhaps-less-hackily) unpacking fay-base somewhere and then using the same option to point to that.

[peti]

My understanding is that fay has fay-base as a build input, right? So clearly it knows the packages absolute path (but apparently doesn't use that information).

[bergmark]

What do you mean by "build input"? cabal build or compiling fay code? On the package level fay-base depends on fay. When compiling fay code there's a two-way dependency, which is what makes it tricky.

[peti]

Ah, I just checked and I see that faydoes in fact NOT depend on fay-base in any way. That seems awkward, considering that fay tries to access the code from fay-base at runtime!

[bergmark]

Right, theres as far as I know no way to enforce this dependency, What we would like to do is to generate a Paths_fay_base module and import that from fay, but we can't because

1. That would introduce a cyclic dependency
2. That would require fay-base to depend on base resulting in ambiguous module names.

And this is why the executable/library provides ways to specify which pkg-db or path to use to find fay-base, where the default calls the ghc-pkg process and uses some heuristics.

[peti]

Okay, so if ghc-pkg describe fay-base knows the proper path, then fay will find it? Did I without further help get that right?

In that case, we can modify the fayexpression so that it makes sure fay-base is visible to ghc-pkg. that should remedy the issue then.

[bergmark]

The way this heuristic works is that fay checks where it's own data-files directory is located by importing its own Paths module, this is typically something like ~/.cabal/share/x86_64-osx-ghc-7.8.2/fay-0.20/, it then uses ghc-pkg describe to find the version number of the requested package (fay-base in this example). It may end up with fay-base and 0.19.1.2, and then it replaces the package name and version in the path it got for fay so we end up with ``~/.cabal/share/x86_64-osx-ghc-7.8.2/fay-base-0.19.1.2/` and then adds that folder as an include directory.

I'm assuming this doesn't match the data-files hierarchy that nix has, otherwise it would just work.

And no, ghc-pkg describe does not know about share directories, this is a Cabal-only concept AFAIK.

[peti]

ghc-pkg knows about library-dirs, though, which can be used to derive the --prefix that was given to the build and thus the default path of the share directory.

[peti]

Please re-open this issue in case it's still relevant.

[abuibrahim]

was this resolved? if yes, what was the resolution.

Still seeing the issues on 16.03.1111.f231b2b:

fay: unable to find (existing) package's share dir: fay-bas