Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Confusion between Sub libraries and packages #10277

Closed
coot opened this issue Aug 26, 2024 · 7 comments
Closed

Confusion between Sub libraries and packages #10277

coot opened this issue Aug 26, 2024 · 7 comments
Labels
re: internal library Concerning internal libraries in packages type: bug

Comments

@coot
Copy link
Collaborator

coot commented Aug 26, 2024

Consider a package which has a sublibrary cborg and also depend on cborg library published on Hackage, e.g.

library ...

library cborg
  build-depends: base,
                 cborg

In such setup I am getting an error since cabal confuses that the cborg sub-library and the Hackage one. I tried to fix this with this:

library ...

library cborg
  build-depends: base,
                 cborg:cborg

but it doesn't help. The only way I found to fix this is to change the sub-library name to x-cyborg - and now it doesn't clash with a published package name, but that's rather unfortunate. I'd expect sublibrary names to be independent namespace, so things like typed-protocols:cborg were possible (instead of rather lengthy typed-protocols:typed-protocols-cborg).

This should be fixed from another perspective. Consider one publishes a package which contains package:sublib, and in the future one publishes sublib to Hackage - which will break the already published package. From this perspective, I tend to think that all sublibraries should always be typed fully qualified, even in their own package. So in the example above, cborg would always mean the published Hackage package cborg, not the package:cborg sublibrary - if one wants that as a dependency, then package:cborg should be used.

@haskell haskell deleted a comment Aug 26, 2024
@ulysses4ever ulysses4ever added re: internal library Concerning internal libraries in packages and removed needs triage labels Aug 26, 2024
coot added a commit to input-output-hk/typed-protocols that referenced this issue Aug 26, 2024
See haskell/cabal#10277, why such long names
are used.
@mpickering
Copy link
Collaborator

What is the error message you get? At which point are things confused?

@fgaz
Copy link
Member

fgaz commented Aug 27, 2024

Seems like a duplicate of #6083. Try using cabal-version: 3.4

@fgaz
Copy link
Member

fgaz commented Aug 27, 2024

This should be fixed from another perspective. Consider one publishes a package which contains package:sublib, and in the future one publishes sublib to Hackage - which will break the already published package. From this perspective, I tend to think that all sublibraries should always be typed fully qualified, even in their own package. So in the example above, cborg would always mean the published Hackage package cborg, not the package:cborg sublibrary - if one wants that as a dependency, then package:cborg should be used.

IIRC the sublibrary has precedence over other packages, so this shouldn't be an issue. From cabal-version 3.4 the qualified syntax is mandatory.

@mpickering

This comment was marked as off-topic.

@mpickering

This comment was marked as off-topic.

@fgaz

This comment was marked as off-topic.

@coot
Copy link
Collaborator Author

coot commented Aug 27, 2024

@fgaz cabal-version: 3.4 indeed fixes it. Thanks!

@coot coot closed this as completed Aug 27, 2024
coot added a commit to input-output-hk/typed-protocols that referenced this issue Aug 27, 2024
See haskell/cabal#10277, why such long names
are used.
@fgaz fgaz changed the title Sub libraries Confusion between Sub libraries and packages Sep 3, 2024
coot added a commit to input-output-hk/typed-protocols that referenced this issue Sep 29, 2024
See haskell/cabal#10277, why such long names
are used.
coot added a commit to input-output-hk/typed-protocols that referenced this issue Sep 29, 2024
See haskell/cabal#10277, why such long names
are used.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
re: internal library Concerning internal libraries in packages type: bug
Projects
None yet
Development

No branches or pull requests

4 participants