How to handle feature requests that add new package dependencies

Question

I am the maintainer of a package on hackage, lrucache. I recently received a feature request for adding instances for Binary and NFData. Both of those are useful things to have, and I have no issue with those instances, in principle.

However, both of them introduce new package dependencies, and I want to keep my package's dependency list as minimal as possible. Is there a sane way to handle this? There are probably well over twenty different packages that provide useful type classes the data structures in lrucache could implement, and get some benefit from.

Obviously, adding all of them as dependencies is a non-starter. But what else can be done?

I can add flags to lrucache.cabal that will enable compiling various instances. That works, in terms of making the dependency list minimal, except when you want it. But it's horrible in the real world, because you can't specify build flags in build-depends sections. So you can depend on a package with a particular flag, but not specify that dependency. This quickly reduces to near-uselessness.

I can create a bunch of orphan instance packages. This has the advantage of allowing dependencies on those instances to be specified in a build-depends section. Its main disadvantage is adding a ton of extra packages to hackage, and needing to maintain them as separate packages.

What else can I do? What's the right thing to do?

Answer 1

Short of an optional dependencies system in cabal (the packaging system) itself, the options aren't too good.

One option is as follows. You can create an additional package of your own for each additional package that you may want your main package to integrate with.

For example, if you would like lrucache to integrate with binary, you could make an additional package lrucache-binary containing the integration (in this case, type class instances). Likewise, a new package of your own lrucache-nfdata to integrate lrucache with nfdata.

Then if someone would like both lrucache and its integration with binary, he can depend on [binary, lrucache, lrucache-binary] together.

Answer 2

What if you just maintain two packages: lrucache, which depends on a zillion different things, and then lrucache-lite (or lrucache-minimal) which is more or less what you have now. Then if people want to minimize their dependencies, they use the lite version, and if they don't care about having a zillion dependencies, they use the standard version. The big one would probably depend on the lite one, to avoid code duplication.