PVP and new public sub-libraries that expose orphan instances

[jonathanknowles]

@danidiaz

I have one question about this. If when developoing an application I only depend on monoidmap but not monoidmap:monoidmap-aeson, does the constraint solver still have to solve for a valid version of aeson, even if it doesn’t need to install it?

Thanks @danidiaz. My naive expectation was that a dependency on monoidmap alone wouldn’t require the constraint solver to solve for a valid version of aeson, but I haven’t been able to confirm this experimentally.

I’ve been experimenting with a minimal empty package that just depends on base and the latest published version of monoidmap (monoidmap-0.0.3.0). Running cabal freeze for the minimal package generates a freeze file that does include aeson. I suspect this is because the test suite of monoidmap has a transitive dependency on aeson.

In any case, I’m starting to think it may be simpler to just publish monoidmap-aeson as a standalone package, for unrelated but practical reasons:

1. Documentation
   It’s relatively easy to build and publish haddock documentation for a standalone package as part of CI. (With public sublibraries, I haven’t yet figured out a reliable way to build integrated documentation for both the main library and public sublibraries.)

2. Independent versioning
   If in future I need to publish updates to monoidmap-aeson, I can do so without having to bump the version of monoidmap.

3. Independent deprecation
   If (for whatever reason) I eventually need to deprecate the monoidmap-aeson package, I won’t need to bump the major version of monoidmap. (Whereas with the public sublibrary solution, this would presumably require a major version bump.)