Change the hashes in the installation report to be a mapping

[pradyunsg]

What's the problem this feature will solve?

Currently, pip install --report generates hash information that looks like:

        "archive_info": {
          "hash": "sha256=18f3e912f9ad1bdec27fb06b8198a2ccc32f201e24174cec1b3424dda605a310"
        }

This means that we can't show hash information with multiple algorithms easily.

Describe the solution you'd like

Change archive information into being a mapping of hashes, similar to PEP 691:

      "hashes": {"sha256": "...", "blake2b": "..."},

We can put this key in archive_info, and replace the existing hash key with it.

Alternative Solutions

Not really. The other option is doing something like adding & as a separator between hashes, but that sounds like a horrible thing to do given the alternatives we have and that we're allowed to make backwards incompatible changes right now.

Additional context

N/A

Code of Conduct

• I agree to follow the PSF Code of Conduct.

[pradyunsg]

/cc @sbidoul

[uranusjr]

For an alternative solution (not suggesting we should do it instead), we can make hashes a list of algo=hashval strings.

[pradyunsg]

It's a mapping -- let's store it as one. I expect that users will compose one anyway, regardless of what format we spew it out in. ([s.split("=") for s in li] vs di.items(), di.get(algo) vs {alternative too difficult to code-golf})

[sbidoul]

Yeah, I've had that in mind too.

I think that should be done as an evolution of PEP 610.

I'm under the impression that PyPI only returns one hash type, though ?

[uranusjr]

The JSON API returns multiple hashes.

[sbidoul]

The JSON API returns multiple hashes.

It is foreseen in the PEP 691 API yes, but in practice pypi.org returns sha256 only.

Anyway I agree this should be done, I'm not sure about the urgency.

[pradyunsg]

Let's do this before we stabilise the format.