Accommodate build systems with their own notion of package names
Motivation
Large-scale multi-language build systems like Bazel have their own notion of package identity different from Cabal's flat alphanumeric-plus-hyphens package names. When building Haskell code with these systems, collections of Haskell modules might have names like //some/path:my_library
rather than, say, distributive
. Current integrations with these systems have to work around the package name validation, e.g. by using only the last path component (https://github.com/tweag/rules_haskell/blob/dfd0161264b3e1ca8e47c30ef258d50e754570fc/haskell/private/pkg_id.bzl#L45) or encoding the label into the set of allowed characters (https://github.com/google/cabal2bazel/blob/master/bzl/private/package.bzl#L32-L55), leading to ugly and confusing package names like someS-SpathS-SmyU-Ulibrary
in various contexts (compiler command lines, package-qualified import syntax, occasionally type errors, and probably others).
More generally, complex builds may identify components with hierarchical paths, and it'd be good to allow them to use their own naming scheme for the corresponding GHC packages without needing to encode them into a highly-restricted set of characters.
Proposal
Change GHC and (if necessary) the Cabal library to allow non-Cabal build systems to use their own preferred formatting for package names (without changing the package naming rules for Hackage or the Cabal build tool). An existing Bazel-specific patch already exists, which accepts Bazel label syntax as package names in GHC flags, package-qualified import syntax, and the Cabal parsers, but it might need to be more general-purpose in order to be merged.