One day we will have bled enough and we'll switch to using cryptographic hashes of package contents (or of some recipe for deterministically building the thing on different architectures) instead of anything so flimsy as a name and version number.

For the humans, we can render the hashes as something friendly, but there's no reason to confuse the machines with our human notions of friendliness.

▲ umanwizard 7 months ago | parent [-]

You’re basically describing nix and Guix.

▲ __MatrixMan__ 7 months ago | parent [-]

They use a hash of the derivation and its inputs as a memoization strategy: providing yesterday's answer to today's question since it was asked yesterday. But so far as I know nobody's actually using those hashes for the initial request.

It's not like python will let you:

   import nix.numpy-hsbdjd...8r5z2 as np

Such that the import mechanism ensures that the correct build of numpy is used.

For that to work you'd have to change nix such that the hash did not digest parameters like `amd64-linux` witch indicated the system architecture (you'd want those to be satisfied at import time).

	▲	umanwizard 7 months ago \| parent [-]
		In Guix at least (I assume also nix) you can build things from source with a verified hash. I.e. write a numpy package definition that says download the Numpy source from this URL, and expect its hash to be equal to this string. You could then depend on that package from another package ensuring it uses a numpy built from that bit-for-bit exact source tree. Does that not amount to the same thing as what you want?