haskell-nix / hnix-store

Haskell implementation of the Nix store
Apache License 2.0
87 stars 23 forks source link

Refactors 2021-06-07 #157

Closed Anton-Latukha closed 3 years ago

Anton-Latukha commented 3 years ago

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

Anton-Latukha commented 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.