Closed Anton-Latukha closed 3 years ago
https://github.com/haskell-nix/hnix-store/pull/161#issuecomment-858529060
Looking good. I wonder - was
ValidAlgo
superfluous?
As it seen. I'd say it was quite an "in advance" type system overfitting.
As I understand, ValidAlgo
was created to have a list of hash algorithms & to gatekeep with the list of "valid hashing algorithms that are supported". Maybe to try to provide & keep own internal hashing type subsystem, and probable included other consequences from writing a type system.
But in the end, code we currently arrived at was&is polymorphic on the hashing algorithms, which regularly(always) have 1 interface&library they come from. Which imposed a question: why is there is a need to gatekeep hash algorithms & keep a list, we actually use only SHA256
, but also just as easy can allow people to use ANY hashing algorithms if they want.
Removing ValidAlgo
both simplified the type system & also allowed the code to work for all of the hashing algorithms provided by cryptonite
library.
But, class NamedAlgo
only has instances that were enumerated in the old HashAlgorithm
. In fact NamedAlgo
exists only because hashing libraries abstain from providing the canonical names for the algorithms, well they are also right, because the industry made it impossible to give canonical names to a number of them: (not even mentioning others) is it SHA256 or SHA-256 of SHA2 or SHA-2?
That relates to SRI-hash form, but that afaik is also not that standartized.
So now we both allow to use any hashing alg, with a small caveat, if they every would use class NamedAlgo
, they would need to provide an instance with their way of naming for the algorithm in use.
Now, we essentially removed the hash type system & logic from HNix-Core & use hashing libraries type system & logic.
Code that stayed is directly relates to Nix store paths & class NamedAlgo
is there to create SRI hashes that Nix ecosystem uses.
Small tweaks & refactors & reorganizations & so - breakages towards flexiblity & easier: #156
~Working on Core compatibility with Remote breaks but
¯\_(ツ)_/¯
what would one do. When I work on particular things I do not want to be forced to do sweeping changes across the stack, prefer to release Core & after that migrate the Remote & release it right after if needed, somewhere in time there is a time to stop synchronously tagging them in the same commit.~ Hey, CI & Nix config - it all works now https://github.com/haskell-nix/hnix-store/pull/160