Stack assumes IPIDs have a specific format

[ezyang]

parseGhcPkgId assumes that an installed package ID is always a package name, a version, and a hash. IPIDs are opaque identifiers generated by Cabal, and Cabal reserves the right to change them (and will be changing them soon, c.f. haskell/cabal#2745 )

[chrisdone]

That issue didn't clarify for me what will become of the format, other than that it will change. Currently we parse (from ghc-pkg dump)

ghcpkgid = packageidentifier "-" hash

where packageidentifier = packagename "-" packageversion

From that module we export access to the packageidentifier (and therefore the name and version of the package), because those are used in the codebase, but we don't expose access to the hash, which is only available as part of the whole when printing or comparing the ghcpkgid data structure.

What will be the new format of the ghcpkgid? Will there be a name and version anymore? What can we expect? If this string will basically be an opaque hash (again, of what format?) with nothing useful in it but to be unique then we'll update the parser to be liberal and remove the packageidentifier accessor from the module and rework the codebase from the bottom up with this new change. If the packagename will remain but version not, we may still be able to recover the version from elsewhere in ghc-pkg dump, etc. Then having stack work on the recent GHC and the new GHC that uses this change is another issue.

[ezyang]

OK, if it is a really big problem for Stack to fix this we can try to keep the full package identifier in the IPID (our change is mostly to the hash format, but we were considering dropping the version to keep symbol names small). However, shouldn't it always be possible to get the package name and version given an IPID by consulting ghc-pkg dump, for both new and old GHCs?

[chrisdone]

It's not a really big problem, it's just vague. If a package id no longer contains anything but a hash, then a re-interpretation of the GhcPkgId type is needed, which will have some small ripples in the codebase. We'll just proceed like this, then it doesn't matter what format you pick in the end. 👍

[ezyang]

OK, well, assuming symbol name sizes don't end up being a problem, it's not too hard to accommodate you guys by keeping the format the same (if you're fine with any sort of alphanumeric hash format).

[snoyberg]

@ezyang What are the restrictions on what an IPID can be? Can it contain spaces? Non-Latin characters? From what I've seen, A-Za-z0-9 and - should be it. Is that accurate?

[snoyberg]

Pull request #902 opened to address this. I'm going to close this issue, let's discuss on the PR