Internal libraries break (?) package.conf.inplace #5857
Labels
Comments
michaelpj
added a commit
to michaelpj/plutus
that referenced
this issue
Jan 23, 2019
The documentation for `addCorePlugin` says it has to be in a separate package to the plugin. However it appears that in GHC's eyes internal libraries in a Cabal package are separate packages, so we can hide all of this in a single package, which is much nicer. We then have to do some shennanigans to get doctest to work. The normal tests work fine, since Cabal registers the built internal library as a package, and that's fine. But doctest interprets things, which *doesn't* work. Now, I initially tried to just pass the appropriate `-package-db` arguments to `doctest`, but in doing so I hit what appears to be a [Cabal bug with internal libraries](haskell/cabal#5857). However, somehow `cabal repl` and friends seem to get around this, and fortunately there is now a `cabal doctest` command, which amazingly also seems to pass the right set of obscure flags. So we use that. Finally, in an extremely irritating discovery, apparently [Haddock doesn't work with internal libraries] (haskell/cabal#4969) (possibly fixed in a newer Cabal, who knows), so I ended up having to exclude `plutus-tx` from Haddock generation for now.
michaelpj
added a commit
to michaelpj/plutus
that referenced
this issue
Jan 23, 2019
The documentation for `addCorePlugin` says it has to be in a separate package to the plugin. However it appears that in GHC's eyes internal libraries in a Cabal package are separate packages, so we can hide all of this in a single package, which is much nicer. We can then organize things a bit more neatly inside. We then have to do some shennanigans to get doctest to work. The normal tests work fine, since Cabal registers the built internal library as a package, and that's fine. But doctest interprets things, which *doesn't* work. Now, I initially tried to just pass the appropriate `-package-db` arguments to `doctest`, but in doing so I hit what appears to be a [Cabal bug with internal libraries](haskell/cabal#5857). However, somehow `cabal repl` and friends seem to get around this, and fortunately there is now a `cabal doctest` command, which amazingly also seems to pass the right set of obscure flags. So we use that. Finally, in an extremely irritating discovery, apparently [Haddock doesn't work with internal libraries] (haskell/cabal#4969) (possibly fixed in a newer Cabal, who knows), so I ended up having to exclude `plutus-tx` from Haddock generation for now.
michaelpj
added a commit
to michaelpj/plutus
that referenced
this issue
Jan 23, 2019
The documentation for `addCorePlugin` says it has to be in a separate package to the plugin. However it appears that in GHC's eyes internal libraries in a Cabal package are separate packages, so we can hide all of this in a single package, which is much nicer. We can then organize things a bit more neatly inside. We then have to do some shennanigans to get doctest to work. The normal tests work fine, since Cabal registers the built internal library as a package, and that's fine. But doctest interprets things, which *doesn't* work. Now, I initially tried to just pass the appropriate `-package-db` arguments to `doctest`, but in doing so I hit what appears to be a [Cabal bug with internal libraries](haskell/cabal#5857). However, somehow `cabal repl` and friends seem to get around this, and fortunately there is now a `cabal doctest` command, which amazingly also seems to pass the right set of obscure flags. So we use that. Finally, in an extremely irritating discovery, apparently [Haddock doesn't work with internal libraries] (haskell/cabal#4969) (possibly fixed in a newer Cabal, who knows), so I ended up having to exclude `plutus-tx` from Haddock generation for now.
michaelpj
added a commit
to michaelpj/plutus
that referenced
this issue
Jan 23, 2019
The documentation for `addCorePlugin` says it has to be in a separate package to the plugin. However it appears that in GHC's eyes internal libraries in a Cabal package are separate packages, so we can hide all of this in a single package, which is much nicer. We can then organize things a bit more neatly inside. We then have to do some shennanigans to get doctest to work. The normal tests work fine, since Cabal registers the built internal library as a package, and that's fine. But doctest interprets things, which *doesn't* work. Now, I initially tried to just pass the appropriate `-package-db` arguments to `doctest`, but in doing so I hit what appears to be a [Cabal bug with internal libraries](haskell/cabal#5857). However, somehow `cabal repl` and friends seem to get around this, and fortunately there is now a `cabal doctest` command, which amazingly also seems to pass the right set of obscure flags. So we use that. Finally, in an extremely irritating discovery, apparently [Haddock doesn't work with internal libraries] (haskell/cabal#4969) (possibly fixed in a newer Cabal, who knows), so I ended up having to exclude `plutus-tx` from Haddock generation for now.
michaelpj
added a commit
to michaelpj/plutus
that referenced
this issue
Jan 23, 2019
The documentation for `addCorePlugin` says it has to be in a separate package to the plugin. However it appears that in GHC's eyes internal libraries in a Cabal package are separate packages, so we can hide all of this in a single package, which is much nicer. We can then organize things a bit more neatly inside. We then have to do some shennanigans to get doctest to work. The normal tests work fine, since Cabal registers the built internal library as a package, and that's fine. But doctest interprets things, which *doesn't* work. Now, I initially tried to just pass the appropriate `-package-db` arguments to `doctest`, but in doing so I hit what appears to be a [Cabal bug with internal libraries](haskell/cabal#5857). However, somehow `cabal repl` and friends seem to get around this, and fortunately there is now a `cabal doctest` command, which amazingly also seems to pass the right set of obscure flags. So we use that. Finally, in an extremely irritating discovery, apparently [Haddock doesn't work with internal libraries] (haskell/cabal#4969) (possibly fixed in a newer Cabal, who knows), so I ended up having to exclude `plutus-tx` from Haddock generation for now.
michaelpj
added a commit
to michaelpj/plutus
that referenced
this issue
Jan 23, 2019
The documentation for `addCorePlugin` says it has to be in a separate package to the plugin. However it appears that in GHC's eyes internal libraries in a Cabal package are separate packages, so we can hide all of this in a single package, which is much nicer. We can then organize things a bit more neatly inside. We then have to do some shennanigans to get doctest to work. The normal tests work fine, since Cabal registers the built internal library as a package, and that's fine. But doctest interprets things, which *doesn't* work. Now, I initially tried to just pass the appropriate `-package-db` arguments to `doctest`, but in doing so I hit what appears to be a [Cabal bug with internal libraries](haskell/cabal#5857). However, somehow `cabal repl` and friends seem to get around this, and fortunately there is now a `cabal doctest` command, which amazingly also seems to pass the right set of obscure flags. So we use that. Finally, in an extremely irritating discovery, apparently [Haddock doesn't work with internal libraries] (haskell/cabal#4969) (possibly fixed in a newer Cabal, who knows), so I ended up having to exclude `plutus-tx` from Haddock generation for now.
|
@michaelpj you seem to have tried with the legacy v1 commands; I tried with v2-build instead: |
|
Unfortunately I did manage to solve my original problem by using a Feel free to close if you're not interested in fixing this. |
|
@michaelpj it's not that we aren't interested, it's rather that the highest priority currently has getting v2-build ready to replace old-build. You say
and since we're going to make it default real-soon it would be great if you can elaborate what is missing so we can try to address that... :-) |
|
Ah sorry, I interpreted that as "we're probably not interested in fixing v1 stuff" which would be reasonable :) I don't think it's anything you don't have tickets for. For my organization at least the following are blockers:
|
|
Hm, I'm observing this also in the package databases produced by Nix. I don't have a minimal reproduction yet, but it's something like:
In this case the combined package db for my dependencies has the package listed as present when I do However, I think I have found a clue:
Now, the docs for -package-id say that it exposes the package with the given id. But the The only thing I can think of that's consistent with all this is that GHC disagrees with |
|
Further evidence that it's just looking for the wrong package id: the error message I get in both cases is not the one you get when you try to import from a hidden package, so it's not the exposure status that's wrong. |
|
Correction:
Both are mitigated either by passing |
|
I opened a trac ticket for this since it seems like |
|
Returning to this, I have a note about |
MangoIV
pushed a commit
to MangoIV/plutus-contract
that referenced
this issue
Sep 3, 2022
The documentation for `addCorePlugin` says it has to be in a separate package to the plugin. However it appears that in GHC's eyes internal libraries in a Cabal package are separate packages, so we can hide all of this in a single package, which is much nicer. We can then organize things a bit more neatly inside. We then have to do some shennanigans to get doctest to work. The normal tests work fine, since Cabal registers the built internal library as a package, and that's fine. But doctest interprets things, which *doesn't* work. Now, I initially tried to just pass the appropriate `-package-db` arguments to `doctest`, but in doing so I hit what appears to be a [Cabal bug with internal libraries](haskell/cabal#5857). However, somehow `cabal repl` and friends seem to get around this, and fortunately there is now a `cabal doctest` command, which amazingly also seems to pass the right set of obscure flags. So we use that. Finally, in an extremely irritating discovery, apparently [Haddock doesn't work with internal libraries] (haskell/cabal#4969) (possibly fixed in a newer Cabal, who knows), so I ended up having to exclude `plutus-tx` from Haddock generation for now.
andreasabel
added
the
re: internal library
kayvank
pushed a commit
to input-output-hk/marconi
that referenced
this issue
Mar 11, 2023
The documentation for `addCorePlugin` says it has to be in a separate package to the plugin. However it appears that in GHC's eyes internal libraries in a Cabal package are separate packages, so we can hide all of this in a single package, which is much nicer. We can then organize things a bit more neatly inside. We then have to do some shennanigans to get doctest to work. The normal tests work fine, since Cabal registers the built internal library as a package, and that's fine. But doctest interprets things, which *doesn't* work. Now, I initially tried to just pass the appropriate `-package-db` arguments to `doctest`, but in doing so I hit what appears to be a [Cabal bug with internal libraries](haskell/cabal#5857). However, somehow `cabal repl` and friends seem to get around this, and fortunately there is now a `cabal doctest` command, which amazingly also seems to pass the right set of obscure flags. So we use that. Finally, in an extremely irritating discovery, apparently [Haddock doesn't work with internal libraries] (haskell/cabal#4969) (possibly fixed in a newer Cabal, who knows), so I ended up having to exclude `plutus-tx` from Haddock generation for now.
kayvank
pushed a commit
to input-output-hk/marconi
that referenced
this issue
Mar 22, 2023
The documentation for `addCorePlugin` says it has to be in a separate package to the plugin. However it appears that in GHC's eyes internal libraries in a Cabal package are separate packages, so we can hide all of this in a single package, which is much nicer. We can then organize things a bit more neatly inside. We then have to do some shennanigans to get doctest to work. The normal tests work fine, since Cabal registers the built internal library as a package, and that's fine. But doctest interprets things, which *doesn't* work. Now, I initially tried to just pass the appropriate `-package-db` arguments to `doctest`, but in doing so I hit what appears to be a [Cabal bug with internal libraries](haskell/cabal#5857). However, somehow `cabal repl` and friends seem to get around this, and fortunately there is now a `cabal doctest` command, which amazingly also seems to pass the right set of obscure flags. So we use that. Finally, in an extremely irritating discovery, apparently [Haddock doesn't work with internal libraries] (haskell/cabal#4969) (possibly fixed in a newer Cabal, who knows), so I ended up having to exclude `plutus-tx` from Haddock generation for now.
|
I fixed this in GHC. |
|
Well done! :) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Observed using Cabal 2.4.1.
Reproduction case here: https://github.com/michaelpj/cabal-bug-package-db
If I add even an empty internal library to my package, the package db in
dist/package.conf.inplaceseems to no longer work.ghc-pkg listshows the packages as there and exposed, but trying to use them withghc -package-dbdoes not work.The text was updated successfully, but these errors were encountered: