Normalizes Derivation inputs and makes it accept different types for all these, which is required to tie some loose ends on hnix/hnix-store side.
I've also removed the (now) useless Functor and Bifunctor instances and passed the lib thru hlint, which doesn't produce any warnings now.
DeriviationOutput is no longer parametrized with text as we replace it completely on our side with
-- | Output of the derivation
data DerivationOutput a = DerivationOutput
{ derivationOutputHash :: DSum HashAlgo Digest
-- ^ Hash modulo of the derivation
, derivationOutputOutput :: a
-- ^ Name of the output
} deriving (Eq, Generic, Ord, Show)
I've realised this when I've tried to implement Nixes Realisation type :upside_down_face:, which also uses DerivationOutput
I hope this accommodates all our needs, and is parametric enough for now - we might want to differentiate between the other txt types in the future though, using some simple newtype wrappers.
I'm tempted to add a type alias to make this look less awkward for downstream users that don't need this level of parametrization (nix-diff, nix-graph), but I'm not sure if it's worth it because then you need to import both Derivation(..) for the fields and the type alias.
I'll try to actually use this first, to see if really fits and then I would add a version bump (possibly CHANGELOG as well), ask you for a release and do the downstream PRs.
Parametrized on
outputName
drvOutput
drvInputs
Normalizes
Derivation
inputs and makes it accept different types for all these, which is required to tie some loose ends onhnix/hnix-store
side.I've also removed the (now) useless
Functor
andBifunctor
instances and passed the lib thru hlint, which doesn't produce any warnings now.DeriviationOutput
is no longer parametrized withtext
as we replace it completely on our side withI've realised this when I've tried to implement Nixes
Realisation
type :upside_down_face:, which also usesDerivationOutput
I hope this accommodates all our needs, and is parametric enough for now - we might want to differentiate between the other
txt
types in the future though, using some simplenewtype
wrappers.I'm tempted to add a type alias to make this look less awkward for downstream users that don't need this level of parametrization (
nix-diff
,nix-graph
), but I'm not sure if it's worth it because then you need to import bothDerivation(..)
for the fields and the type alias.I'll try to actually use this first, to see if really fits and then I would add a version bump (possibly
CHANGELOG
as well), ask you for a release and do the downstream PRs.