GHC does not shadow -package-name/-this-package-key
Steps to reproduce:
- Install a package named
a
with these contents:
**a.cabal**
name: a
version: 0.1.0.0
cabal-version: >=1.10
library
exposed-modules: A
build-depends: base
- *A.hs**
module A where
data A = A String
Note what unit ID/package key/package name the package installs as. On GHC 7.8 it will be something like
a-0.1.0.0
, on GHC 7.10 it will be something likea_LKCPrTJwOTOLk4OU37YmeN
, on GHC 8.0 it will be something likea-0.1.0.0-LKCPrTJwOTOLk4OU37Yme
.
- Install a package named
b
with these contents:
**b.cabal**
name: b
version: 0.1.0.0
cabal-version: >=1.10
library
exposed-modules: B
build-depends: base, a
- *b.hs**
module B where
import A
b = A "foo"
- Go back to
a
, and loadA.hs
in GHCi withghci A.hs -package-name a-0.1.0.0 -package-db ../db
. Notice that we canimport B
from this GHCi session:
ezyang@sabre:~/Dev/labs/ii/a$ ghci A.hs -package-name a-0.1.0.0 -package-db ../db
GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
[1 of 1] Compiling A ( A.hs, interpreted )
Ok, modules loaded: A.
*A> import B
*A B> b
Loading package a-0.1.0.0 ... linking ... done.
Loading package b-0.1.0.0 ... linking ... done.
A "asdfsdf"
*A B>
Leaving GHCi.
- Edit
A.hs
so that now contains:
module A where
data A = A Int
- Load in GHCi again:
ezyang@sabre:~/Dev/labs/ii/a$ ghci A.hs -package-name a-0.1.0.0 -package-db ../db
GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
[1 of 1] Compiling A ( A.hs, interpreted )
Ok, modules loaded: A.
*A> import B
*A B> b
Loading package a-0.1.0.0 ... linking ... done.
Loading package b-0.1.0.0 ... linking ... done.
A 3458765062984598387
Disaster!
Actually, this bug is relatively harmless:
- If you try to actually reinstall package a, that's a "dangerous" reinstall and it's known that reinstalls can break things.
- It's hard to convince Cabal to trigger this, since importing
B
requiresb
in the build-depends, and that would constitute a circular package dependency. (You can't separate it out because of (1)) - If you don't specify
-package-name
(or similar) the localA
and the remoteA
will have different identities, no problem. - When you do specify
-package-name
, you can't build a main executable (so the only way to run is by loading into GHCi, as shown above.) - Sometimes, GHCi will notice that something is amiss if it tries to load the object file for both the remote A and the local A.
But the fix seems simple: if a user specifies -package-name
, it should be AS IF they also specified -ignore-package
.
Trac metadata
Trac field | Value |
---|---|
Version | 7.11 |
Type | Bug |
TypeOfFailure | OtherFailure |
Priority | low |
Resolution | Unresolved |
Component | Package system |
Test case | |
Differential revisions | |
BlockedBy | |
Related | |
Blocking | |
CC | |
Operating system | |
Architecture |