Package versions in API dump? Is this the intended behaviour?

[alaendle]

Guess this is to avoid some ambiguities of symbols, but for some identifier I get packages with versions in my API dump.

E.g.

Call :: forall (m :: * -> *). bytestring-0.11.5.3:Data.ByteString.Internal.Type.ByteString -> Faas m (Data.Either.Either (GHC.Types.Int, bytestring-0.11.5.3:Data.ByteString.Internal.Type.ByteString) (bytestring-0.11.5.3:Data.ByteString.Internal.Type.ByteString, bytestring-0.11.5.3:Data.ByteString.Internal.Type.ByteString))

Or the same with aeson:

SetModuleTwinHandler :: forall a1 (m :: * -> *). (GHC.Classes.Eq a1, aeson-2.2.3.0:Data.Aeson.Types.FromJSON.FromJSON a1) => (a1 -> m ()) -> IoTHub m ()

But his just creates noise if the aeson/bytestring version changes, and also it feels inconsistent - e.g. Either or Int are not "package-prefixed".

[Kleidukos]

To answer your last sentence, I imagine it's because base and ghc-internal are not re-installable, and as such the version does not matter.

[Kleidukos]

This certainly makes me think about using a different backend for the interface dump. Thanks for reporting this.

[andreabedini]

How about this: hide the unit-id by default and show it only when there are multiple instances of a same package name (or requested by the user with a flag perhaps).

It requires a bit logic but nothing compared to what you have already done.

[Kleidukos]

Yes that could work. :)

[Kleidukos]

@andreabedini you reckon you could come up with a prototype PR for this?

[geekosaur]

Part of this is a wart in ghc/ghc-api: if names are directly imported (including the default import of Prelude) then they're reported in short form, but names brought in transitively are fully qualified with unit ids. You can also see this in ghc's own error messages. I don't think ghc-api allows you to change this.

[andreabedini]

Yes that could work. :)

Yes, as soon as I have some free time :-)