Consider deriving more instances.

[expipiplus1]

It's unfortunate that often deriving every possible class pulls in the world in (sometimes unnecessary) dependencies. As far as I know the options are:

• Do nothing and leave creating orphans to the users
• Publish orphans in a separate package uom-plugin-quickcheck-orphans for example
• Publish instances in the uom-plugin package, pulling in heaps of dependencies
• Publish instances in the uom-plugin package compiled conditionally on flags, I'm not sure what cabal's behaviour is when flags conflict between different dependencies on uom-plugin

One package without too many dependencies is random which would make a sensible addition I think.

[adamgundry]

Yes, this is a bit of an annoying issue. How about the compromise solution of a single new package (uom-plugin-orphans) that pulls in all the non-base dependencies and declares all the instances in one place? That saves maintaining lots of tiny packages, and avoids piling too many dependencies on the core library for people who may want to experiment with it.

[ghost]

This seems reasonable. Actually, I don't think there's any other choice than a) pulling all the dependencies into the base package b) bugging the GHC team to allow multiple standalone deriving clauses in the same code (I guess this should be possible in theory, as the deriving mechanism is surely deterministic, but alas). But I still think that Unbox could be defined in uom-plugin proper. My reasoning is that it's likely that people are going to use both vector and uom-plugin in the same code, given that both are useful for physics-related number crunching, and also that vector is mentioned in https://wiki.haskell.org/Library_submissions even though it's considered non-core.

EDIT: well, if annoying the GHC team is considered a viable option, there's one more choice: ask them to allow declarations like deriving ALL BUT Num, which I think would be fine for Quantity - after all it's exactly the same thing as the underlying type, except for arithmetic operations?

[expipiplus1]

Having an 'orphans' package is better than having every dependency piled onto the main package, but it still makes people suffer build times linear in the number of instances available, rather than number of instances used :(