Add support for visibility: public

[expipiplus1]

Thanks for the super tool!

It would be really nice to have support for multiple public libraries: https://fgaz.me/posts/2019-11-14-cabal-multiple-libraries/

At the moment it seems possible to do with verbatim: visibility: public as below, but it seems nasty to have to put these libraries in internal-libraries.

internal-libraries:
  foo:
    source-dirs: foo
    verbatim:
      visibility: public
    dependencies:
      - base < 4.14

[sol]

@expipiplus1 can you please try #385? Does this work for you?

[expipiplus1]

@sol, works great, thanks!

[Ptival]

@expipiplus1 have you been able to import the exposed public library though?

When I try putting package:library in a dependency field, hpack outputs package only.

[sol]

@Ptival I didn't have the need for this myself, but if having a dependency on a public library doesn't work then this is probably something we want to fix. If you can provide a minimal test case (as I understand it, we would need two packages for this, one that exports the library and one that depends on it), then I'll try to find the time to fix it.

[expipiplus1]

@Ptival, I didn't try to import such a package using hpack, no. From what I understand you're talking about the dual of this issue.

…

On Sat, May 30, 2020, 4:55 AM Simon Hengel ***@***.***> wrote: @Ptival <https://github.com/Ptival> I didn't have the need for this myself, but if having a dependency on a public library doesn't work then this is probably something we want to fix. If you can provide a minimal test case (as I understand it, we would need two packages for this, one that exports the library and one that depends on it), then I'll try to find the time to fix it. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#382 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGRJXGXN43J7PNBZMHJDBTRUAOM7ANCNFSM4MF3SLIA> .

[Ptival]

Yes, it is indeed the other side of the picture.

@sol

In terms of minimal example, if you write a package.yaml like:

dependencies:
  - base
  - package
  - package:library

library:
  other-modules: []

name: my-other-package

verbatim:
  cabal-version: 3.0

The output is:

cabal-version: 3.0

-- This file has been generated from package.yaml by hpack version 0.34.1.
--
-- see: https://github.com/sol/hpack

name:           my-other-package
version:        0.0.0
build-type:     Simple

library
  build-depends:
      base
    , package
  default-language: Haskell2010

When it should be:

cabal-version: 3.0

-- This file has been generated from package.yaml by hpack version 0.34.1.
--
-- see: https://github.com/sol/hpack

name:           my-other-package
version:        0.0.0
build-type:     Simple

library
  build-depends:
      base
    , package
    , package:library
  default-language: Haskell2010

Without it, my-other-package will not be able to import modules from package:library.

[sol]

For me

dependencies:
  - base
  - package
  - package:library

results in a parse error. @Ptival what version of hpack are you using?

We want to address this, but for the meantime, this can be used as a workaround:

dependencies:
  - base
  - package
  - name: package:library

[sol]

Ok, so the current behavior depends on the version of Cabal that hpack was built against.

[Ptival]

hpack-0.34.1, built with GHC 8.8.2 against Cabal-3.0.0.0.

Thanks for the workaround! (it works)

[sol]

On Hackage as hpack-0.34.2. @Ptival you won't need to specify cabal-version: 3.0 anymore, hpack should infer it.

[Ptival]

Sorry, turns out overriding hpack in nix is a bit of an adventure!

I can confirm that it works, and inserts cabal-version properly.