Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cooperate with stack and cabal to find the package-db #129

Open
gelisam opened this issue Apr 20, 2021 · 4 comments
Open

cooperate with stack and cabal to find the package-db #129

gelisam opened this issue Apr 20, 2021 · 4 comments

Comments

@gelisam
Copy link
Contributor

gelisam commented Apr 20, 2021

currently, hint's package database is configured in the same way ghc is, via environment variables and -package-db arguments. This is super old-school, nowadays people use a .cabal file to specify which packages they want their programs to see. It would be great if that just worked out of the box without having to jump through hoops in order to set the right settings. At the very least, how to specify package databases should be documented somewhere.

@yaitskov
Copy link

@gelisam, ghc-pkg looks at GHC_PACKAGE_PATH and --package-db argument, but unsafeRunInterpreterWithArgs (ghc 8.10.2) ignores both.

being in nix-shell cabal builds my app and ghc-pkg list prints path to the package database, but
I don't know how specify package database location for the compiled program.
Basic linking is working for the elf file, because optparse help command is executed, but hint feature is not working.

@gelisam
Copy link
Contributor Author

gelisam commented Apr 29, 2021

ghc-pkg looks at GHC_PACKAGE_PATH and --package-db argument, but unsafeRunInterpreterWithArgs (ghc 8.10.2) ignores both.

What makes you say that? If I install e.g. the colour package via stack and then run a program which uses hint with and without the flags which point it to stack's package database, I get different results:

import Data.Foldable (for_)
import Language.Haskell.Interpreter as Hint
import Language.Haskell.Interpreter.Unsafe as Hint

-- |
-- >>> main
-- with args:
-- result:
-- <no location info>: error:
--     Could not find module ‘Data.Colour’
--     Use -v (or `:set -v` in ghci) to see a list of the files searched for.
-- with args:
--   -package-db
--   /Users/gelisam/.stack/snapshots/.../8.10.4/pkgdb
-- result:
-- Data.Colour.SRGB.Linear.rgb 0.0 0.0 0.0
main :: IO ()
main = do
  let packageDbConfigs = [ []
                         , ["-package-db", "/Users/gelisam/.stack/snapshots/.../8.10.4/pkgdb"]
                         ]
  for_ packageDbConfigs $ \packageDbConfig -> do
    putStrLn "with args:"
    for_ packageDbConfig $ \arg -> do
      putStrLn $ "  " ++ arg
    putStrLn "result:"
    r <- Hint.unsafeRunInterpreterWithArgs packageDbConfig $ do
      Hint.setImports ["Prelude", "Data.Colour"]
      Hint.eval "mempty :: Colour Double"
    case r of
      Left (WontCompile [GhcError errMsg]) -> do
        putStrLn errMsg
      Right s -> do
        putStrLn s

@yaitskov
Copy link

yaitskov commented May 5, 2021

In my case -package-db and GHC_PACKAGE_PATH don't help anyhow.

GHC_PACKAGE_PATH="/nix/store/h1bikz8x8v5g88b0vk78xdncckivan4j-ghc-8.10.4-with-packages/lib/ghc-8.10.4/package.conf.d:" my-elf-file
in the app:

unsafeRunInterpreterWithArgs [ "-package-db", "/nix/store/h1bikz8x8v5g88b0vk78xdncckivan4j-ghc-8.10.4-with-packages/lib/ghc-8.10.4/package.conf.d", "-package" , "myapp" ] 

GhcException "cannot satisfy -package myapp

But replacing package.cache in user conf ref solves problem:

rm ~/.cabal/store/ghc-8.10.4/package.db/package.cache
ln -s /nix/store/h1bikz8x8v5g88b0vk78xdncckivan4j-ghc-8.10.4-with-packages/lib/ghc-8.10.4/package.conf.d/package.cache   ~/.cabal/store/ghc-8.10.4/package.db/

Interpreter is working.
Let's break it with "-no-user-package-conf"

unsafeRunInterpreterWithArgs [  "-no-user-package-conf" ]

Still working! So I conclude that unsafeRunInterpreterWithArgs understands -package arguments.

@gelisam
Copy link
Contributor Author

gelisam commented May 5, 2021

I can only repeat once again that I do not recommend having code from package X interpret code which imports a module from package X :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants