CODEWITHSUNDEEP
haskellhaskell-stack
orome
orome

Reputation: 48516

Workflow for using stack to test Hackage packages (not in Stackage)

What is the workflow for using stack to preform an isolated download and install (for testing and experimentation) of a Haskell package that's in Hackage, but not in Stackage?

For example

stack new tester
cd tester
# Then add the package PKG to 'extra-deps'
stack build . --force-dirty

is not sufficient, and results in errors ("not a module in the current program, or in any known package") when an import of part of the package is attempted.

Explicitly building the package (which seems like it shouldn't be necessary) with

stack build PKG

doesn't work either (resulting in warnings that it "is a member of the hidden package PKG...").

If I instead simply

stack new tester --force 
cd tester 
stack build PKG

I get the same "hidden package" error when I try to import a component of the package in a stack ghci session.

What is the (best practice) workflow for using Haskell stack to create an isolated temporary installation for a working with specific package on Hackage?

Upvotes: 1

Views: 401

Answers (1)

sjakobi
sjakobi

Reputation: 3606

To play with a package that isn't available on Stackage, I usually first try to build it in the global project:

$ cd ~/
$ stack build the-package
$ stack ghci

If that doesn't work, usually because of missing dependencies or bounds issues, I resort to the following workflow:

$ stack new playground
$ cd playground
# In playground.cabal, add the-package to the library build-depends section 
$ stack solver --update-config
$ stack ghci
# Play with the package

Upvotes: 1

Related Questions