Suggestion: fix all nix hash snippets to use `lib.fakeHash`

[Eveeifyeve]

I have a suggestion to make instead of writing the hashes that will be replaced with the actual hash what if we use the lib.fakeHash instead of sha256-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA which is a sensible option for getting a fakeHash when making a derivation for nixpkgs.

CC @doronbehar, @HeitorAugustoLN

---

Add a 👍 reaction to issues you find important.

[Eveeifyeve]

I will be happy to make it in pr #541 if needed.

[doronbehar]

Hmm not necessarily lib is available. Not only that, I personally like how the explicit sha256-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= hash makes it easy to spot how many characters you need in the hash, and hence may help avoid copy paste issues that may miss a character.

[Eveeifyeve]

Hmm not necessarily lib is available. Not only that, I personally like how the explicit sha256-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= hash makes it easy to spot how many characters you need in the hash, and hence may help avoid copy paste issues that may miss a character.

I mean isn't this ment to be for derivations and for example the fetchFrom and other fetch snippet could in theory use the lib.fakeHash, but leave the hash one still available, because it annoying in a way when I do a fetchfrom snippet when making a derivation I have to delete the hash to use lib.fakeHash.

[Eveeifyeve]

To the point, I am about to soon disable the nix snippets and make a custom one for my neovim, because it's simply annoying.

[Eveeifyeve]

Or even just having the choice available would be nice.

[doronbehar]

Or even just having the choice available would be nice.

That indeed would be nice, but I'm not sure the editors' plugins etc support such functionality.

I mean isn't this ment to be for derivations and for example the fetchFrom and other fetch snippet could in theory use the lib.fakeHash, but leave the hash one still available, because it annoying in a way when I do a fetchfrom snippet when making a derivation I have to delete the hash to use lib.fakeHash.

I could barely understand your phrasing, but I'm taking a guess that you think that deleting from the editor the characters of lib.fakeHash is easier in comparison to deleting the characters sha256-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=? You may have a point here.

[Eveeifyeve]

Or even just having the choice available would be nice.

That indeed would be nice, but I'm not sure the editors' plugins etc support such functionality.

I mean isn't this ment to be for derivations and for example the fetchFrom and other fetch snippet could in theory use the lib.fakeHash, but leave the hash one still available, because it annoying in a way when I do a fetchfrom snippet when making a derivation I have to delete the hash to use lib.fakeHash.

I could barely understand your phrasing, but I'm taking a guess that you think that deleting from the editor the characters of lib.fakeHash is easier in comparison to deleting the characters sha256-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=? You may have a point here.

What I mean is for the fetcher snippets aka fetchfrom.... and fetchgit in this case could use the lib.fakeHash instead of sha256 a hash but still keep the hash snippet available or give the option to put what you want in the fetcher for hash instead of having one by default.

[doronbehar]

I agree that the hash snippet shouldn't be deleted. But I want to know exactly what are your arguments for favoring lib.fakeHash v.s the explicit sha256-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=?

[Eveeifyeve]

I feel like the proper way of getting a hash is by doing the lib.fakeHash as not many people know how the fetchers calculates the hash. You can read more about this here on nixpkgs manual, but it's always the lib.fakeHash instead of "" method, as it could mean any hash is expected.

[doronbehar]

With all due respect to the manual, lib.fakeHash is simply identical to sha256-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=. So I don't see why you should care about this so much.

[Eveeifyeve]

With all due respect to the manual, lib.fakeHash is simply identical to sha256-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=. So I don't see why you should care about this so much.

Well it might want to be considered as users might not understand this is a fake hash and think that it's a real hash then not. It also makes it annoying for users that want to use the lib.fakeHash method of doing sha256-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=, which becomes annoying overtime making a lot of derivations for nixpkgs for example.

[Eveeifyeve]

That's why I am more considering to exclude the snippet for now until we sort out either we add it as an option to use lib.fakeHash or replace the sha256-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=.

In my opinion I feel like the fetchers should be nothing inside by default like hash = $4; as there is already a hash snippet available and another snippet could be introduced for the lib.fakeHash prefixed under hash.

[doronbehar]

users might not understand this is a fake hash and think that it's a real hash then not

Haha if this is the kind of users we are worried about, I would worry first how come they were given a computer in the first place!

You should really work on your punctuation, I can barely make sense of what you write, and I don't want to spend further time in this discussion, sorry. I'm not totally against your proposal, but I don't think I'll approve it, especially if the commit message will be phrased as bad as these comments.

[Eveeifyeve]

Okay not to be rude or anything, I might even mention this in a previous issue about creating a contributing and considering creating a code of conduct for your behaviour today based on how you act to your pears is extremely rude.

I will also kindly please reflect on your behaviour making a review on my pr and issues thankyou.

You should really work on your punctuation, I can barely make sense of what you write,

I will also take the time to improve my punctuation as well, thanks for mentioning it.