[RFC] Plugin dependencies

[ezyang]

Pursuant to https://ghc.haskell.org/trac/ghc/ticket/11244, it would be preferable for users to stop putting plugin dependencies in build-depends and a new field.

I propose to introduce a new field, plugin-depends, which has the same format as build-depends, but adds dependencies on plugins. Packages specified here:

1. Do not get put in the depends in the installed package info (so they don't get linked in when you build an executable),
2. Are passed to GHC 8.0 as -plugin-package-id (with -hide-all-plugin-packages), which forces GHC to only use them to determine scoping of plugin modules, e.g. -fplugin ModName). Previous versions of GHC, they get passed in as normal -package-id flags for backwards compatibility

[23Skidoo]

+1, sounds sensible.

/cc @dcoutts

[ezyang]

OK, one minor complication here: if a user put a plugin dependency in build-depends, we want this to keep working. But this will stop working if Cabal unconditionally passes -hide-all-plugin-packages to GHC 8.0 or later. Perhaps use of -hide-all-plugin-packages should be toggleable, or maybe based on the version of Cabal dependency declared? (So, if a user requires a recent enough version of Cabal, then we assume that they correctly used ghc-plugins)

[23Skidoo]

or maybe based on the version of Cabal dependency declared? (So, if a user requires a recent enough version of Cabal, then we assume that they correctly used ghc-plugins)

I think that's better than adding yet another obscure switch. We'll need a version check for ghc-plugins anyway. We can also hardcode the list of known GHC plugins released on Hackage and warn if a GHC plugin is found in build-depends.

[ezyang]

I previously claimed that plugin-depends should be implemented similarly to build-tools. But I looked more carefully at build-tools and actually, these are not handled at all by the solver (#220). So build-tools is not a good way of implementing this.

Instead, we need plugin-depends to be MERGED with build-depends when we are doing dependency solving; from the dependency solver's perspective, there's no distinction between these two fields. (Actually, if we wanted to be a bit more clever, each plugin dependency should be treated like a setup dependency, since it's OK if a plugin uses foo-0.1 but the main library uses foo-0.2: they won't actually interact.)

Arguably, this field would also be applicable to build-tools: you would specify what executables you depend on build-tools and specify the packages that provide them in plugin-depends (or maybe tool-depends, because we want a more general name). However, it is a bit awful user experience to require users to type in both build-tools: alex; tool-depends: alex so maybe a tool dependency on a package with executables should IMPLY the build-tools on that executable. (One could conceivably have a package which has multiple executables, and you only want to build-tools on one, but that seems awfully remote.)

[cartazio]

i presume this is a cabal > 1.24 feature? :)

[23Skidoo]

@cartazio Yes, it won't be in 1.24.

[tseenshe]

I would like to note that this feature request would be very useful to me as a tooling author, see https://gitlab.com/tseenshe/hsinspect