-
Notifications
You must be signed in to change notification settings - Fork 697
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
Comments
See haskell/cabal#10277, why such long names are used.
What is the error message you get? At which point are things confused? |
Seems like a duplicate of #6083. Try using |
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. |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
@fgaz |
See haskell/cabal#10277, why such long names are used.
See haskell/cabal#10277, why such long names are used.
See haskell/cabal#10277, why such long names are used.
Consider a package which has a sublibrary
cborg
and also depend oncborg
library published on Hackage, e.g.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: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 liketyped-protocols:cborg
were possible (instead of rather lengthytyped-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 publishessublib
to Hackage - which will break the already publishedpackage
. 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 thepackage:cborg
sublibrary - if one wants that as a dependency, thenpackage:cborg
should be used.The text was updated successfully, but these errors were encountered: