CODEWITHSUNDEEP
haskellcabalhaskell-stack
frabrooks
frabrooks

Reputation: 155

How do I instruct cabal-install or stack to use a local version of a hackage package?

Say I want to tinker with a few hackage packages that depend on each other and run

stack unpack foo-1.2.0

and

stack unpack bar-1.0.0

where bar depends on foo.

Now, to build my modified bar with my modified foo, I specify in my bar.cabal:

build-depends:

  foo == 1.2.0

and add to my bar's stack.yaml:

packages:
  - .
  - rel/path/to/foo-1.2.0/

This works, and builds fine but it seems that if a dependency of bar, say some-package, itself depends on foo it will default to the hackage version rather than compile with my modified version despite my modified version meeting the version constraints. Is there a way to force other dependencies further up the chain to use my local version of the package during the build process? I appreciate this is a very unusual use case.

Weirdly I'm able to build fine but trying to load into stack ghci fails with:

Couldn't match type `foo-1.2.0:Some.Type.InFoo.aDataType`
               with `aDataType`
NB:    `aDataType` is defined at
       `full/path/to/foo-1.2.0/Some/Type/InFoo.hs:(23,1)-(28-60)`
       `foo-1.2.0:Some.Type.InFoo.aDataType`
         is defined in `Some.Type.InFoo`
            in package `foo-1.2.0`
       Expected type: `aDataType`
       Actual type: `foo-1.2.0:Some.Type.InFoo.aDataType`

Upvotes: 3

Views: 270

Answers (1)

danidiaz
danidiaz

Reputation: 27766

According to the Cabal User Guide, when developing a project with several local packages:

Local packages, as well as the external packages [...] which depend on them, are built inplace, meaning that they are always built specifically for the project and are not installed globally.

So it seems that even external packages (that is, packages from Hackage or another package repository) will use the local packages, at the cost of needing to be rebuilt for the current project.

Upvotes: 1

Related Questions