Reputation: 155
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: 269
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