Often when writing a new nix expression I am faced with the need to make up with a valid sha256 just to try evaluating the expression and pull the real hash from the resulting error. The hash validity check makes this unnecessarily cumbersome since I need to find a hash elsewhere and then modify it to ensure that a rebuild occurs.
I suggest that the hash attribute validation learn to accept a particular placeholder string (e.g. !) as a valid digest. This would remove a great deal of friction from the process of crafting an expression.
FWIW I just insert 52 1's, which in vim can be done with: "52i1
and C-u 52 C-u 1 for users of the one true editor.
You are all heretics because clearly 64 zeros are the way to go. At least you don't need to remember weird constant 52. (64 base-16 4-bit nibbles is obviously 256, and 256 is in the name of the hash)
As a workaround I prefer to go to the start of the string and then type this vim:
vt"r0
So I do not need to care about length, but still I need to copy some random hash.
An alternative is that in the case of a missing hash attribute, the correct hash is reported in a user friendly manner.
I have a snippet in Atom (_hides_):
'.source.nix':
'sha256 hash':
'prefix': 'sha256'
'body': '''
sha256 = "${1:0000000000000000000000000000000000000000000000000000}";
'''
An alternate solution would be to make something available that you can plugin as a placeholder, say lib.emptyhash
@bgamari given all these suggestions can this issue be closed now?
@aanderse From my perspective, the issue it not resolved at all. These are all work arounds.
Thank you for your contributions.
This has been automatically marked as stale because it has had no activity for 180 days.
If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity.
Here are suggestions that might help resolve this more quickly:
Does lib.fakeSha256 not fix this?
This thread predates fakeSha256 - 68a6b47b8cdbcef4cab3a1f5fae7667a792c27eb.
Most helpful comment
You are all heretics because clearly 64 zeros are the way to go. At least you don't need to remember weird constant 52. (64 base-16 4-bit nibbles is obviously 256, and 256 is in the name of the hash)