Closed exarkun closed 2 years ago
In an strace of the Python process doing the import, I do notice:
newfstatat(AT_FDCWD, "Data/Hashable.hs", 0x42006edc50, 0) = -1 ENOENT (No such file or directory)
newfstatat(AT_FDCWD, "Data/Hashable.lhs", 0x42006edd80, 0) = -1 ENOENT (No such file or directory)
newfstatat(AT_FDCWD, "Data/Hashable.hsig", 0x42006edec0, 0) = -1 ENOENT (No such file or directory)
newfstatat(AT_FDCWD, "Data/Hashable.lhsig", 0x42003d1010, 0) = -1 ENOENT (No such file or directory)
Thank-you for your interest in hyphen! I'm sorry that building isn't going as smoothly for you as I would have hoped.
It looks like the problem is that Data.Hashable
has not been built in a way that is visible in the environment to every running program. In particular, it seems as though it is visible to ghc
(invoked via build-extn.py
at build time), otherwise the build would fail. But it is not available to the python3
process you invoke which import
s hyphen. Reading this page seems to suggest that the way haskellPackages.ghcWithPackages
works is actually a little subtle: it wraps various haskell related executables (like ghc
, ghci
, runhaskell
and so on) with new versions that set magic environment variables so that the packages nix has installed can be found. My guess is that the problem arises because those magic environment variables are not being set for the python3 process, so hyphen
(living inside that process) can't find the binaries of the packages nix compiled.
To test my hypothesis, could you please try invoking a python3 process inside ghci, as follows:
$ ghci
GHCi, version X.Y.Z: http://www.haskell.org/ghc/ :? for help
Prelude> :! python3
Python 3.9.7 (default, Oct 25 2021, 01:04:21)
[GCC 9.3.1 20200408 (Red Hat 9.3.1-2)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import hyphen
If I'm right, then the magic environment variables will be set in the ghci process (because ghci is one of the program names that nix monkey-patches so that they pick up the magic environment vars), and thus, hopefully, in the python3 subprocess that I invoke inside it... which would mean that hyphen
can be imported.
[The one other potential problem I can foresee is that you may not be building dynamic versions of the libraries, as described in BUILDING
. I'm not sure how to get nix to do that... we can cross that bridge when we get to it though...]
[Also: I'm not sure how attached you are to using nix to build the background packages. If it's easy for you to switch to cabal
(as per the BUILDING
file) or stack
then I can try to advise you to get that working. If you'd prefer to stick to nix, I can try my best to help with that too. (If it's helpful, the CI configuration contains example scripts to do the whole build through stack
as well as cabal
.)]
Thanks again for your interest in hyphen
!
Thank-you for your interest in hyphen! I'm sorry that building isn't going as smoothly for you as I would have hoped.
Thanks for the quick reply, and no worries about the build problems. I recognize this is a work in progress. :)
To test my hypothesis, could you please try invoking a python3 process inside ghci, as follows:
The evidence is consistent with your hypothesis:
$ ghci
GHCi, version 8.10.7: https://www.haskell.org/ghc/ :? for help
Prelude> :! python3
Python 3.9.6 (default, Jun 28 2021, 08:57:49)
[GCC 10.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import hyphen
>>> hyphen.hs.Data.ByteString.ByteString.append(b"foo", b"bar")
b'foobar'
And your explanation makes sense to me as well (based on my general understanding of the use of wrapping in NixOS, but I haven't tried to learn about the ghc-related wrappers specifically).
Speculating about how I might have helped myself here ... I could have tried to learn more about the environment ghcWithPackages
gives me and then maybe made the leap to Python3 being missing the ghc-related wrapping. As I filed the ticket, a question I had in the back of my head was about how hyphen actually works ... what does it need to discover at runtime vs compile time? Now it occurs to me to grep for ghc-pkg
and I see there's a great comment in hyphen/loading_source.py that mentions it. I'll have to take some time to digest it, probably (I'm more familiar with Python and Nix than I am with how ghc works).
Anyhow, for the immediate future, I am not blocked in my attempts to play with hyphen. Thank you again.
I'm glad to be of assistance! I'll keep the issue open for a little while longer, in case you hit any other problems. Happy haskelling/pythoning!
Closing this ticket. Please don't hesitate to open another one if you have further questions. I'm also interested to hear any suggestions for improvements that may have occurred to you!
hyphen seems like a very cool project. I wanted to try it out just to get a feel for its behavior. I was unable to build a working version though. Here's a transcript of my effort: