[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

[phadej]

OK, one minor complication here: if a user put a plugin dependency in ...

This can (and should) be guarded by cabal-version: no problems here.

[michaelpj]

It seems to me that rather than plugin-depends we would be better off with native-build-depends. The idea of "native" dependencies is common to many other systems, and it naturally includes build-tools (and arguably setup-depends).

[phadej]

@michaelpj GHC has -plugin-package-id argument, thus plugin-depends. build-tool-depends and plugin-depends are different enough, former are executables, latter are libraries.

[michaelpj]

GHC has -plugin-package-id argument, thus plugin-depends

IMO GHC should also have a separate -native-package-db, but that's another kettle of fish.

[phadej]

@michaelpj yes. I agree with that. And cross-compiler simply should, there is no other way to them even work. I have no idea how you can, or can you at all, use any plugins with cross compiler currently.

---

And if template haskell step would ever be separated, then a separate package db & dependencies for that too.

[michaelpj]

I have no idea how you can, or can you at all, use any plugins with cross compiler currently.

I think @angerman has made this work with some hackery, but conceptually plugins make sense as native library dependencies: they're compiled for the host, so can be linked against the (host) GHC.

[cdsmith]

What is the ghc-plugins referenced in this discussion? I cannot find any mention of it in current Cabal docs. Was it a plan that was abandoned?