pip fork to experiment with PEP-458 implementation https://www.python.org/dev/peps/pep-0458/: See branch tuf-v2 (and tuf-mvp and tuf-mvp-vendored for earlier work)
We could add configuration that states that tuf metadata for https://pypi.org/simple is in $DATADIR/pip/tuf/repos/pypi/.
But client configuration is bad and we can avoid it. Something like this:
# handle things like slash in the end, optional port
canonical_url = canonicalize(index_url.encode('utf-8'))
repo_name = hashlib.sha224(canonical_url).hexdigest()
So warehouse index_url “https://pypi.org/simple/” means tuf repository name “bde14d7cdde6cf8144e84173445c3916263b3a4e7a505cb07603f25c”. This way we can ship the pypi.org metadata with pip and 3rd parties can install their own TUF metadata dirs and there is no configuration required
I've gone through some revisions of this and have come back to using a hash (and not a quoted url or a base64 encoded url).
Reasons:
quoting a url until it's usable as a filename might be possible and quite nice from human readibility POV -- but it's not trivial to get right and...
both quoted url and base64 url have potential issues with maximum filename length: It's unlikely that index urls would be that long but a 200 byte URL is not inconceivable and that would already lead to an invalid filename if base64 encoded
We could add configuration that states that tuf metadata for https://pypi.org/simple is in $DATADIR/pip/tuf/repos/pypi/.
But client configuration is bad and we can avoid it. Something like this:
So warehouse index_url “https://pypi.org/simple/” means tuf repository name “bde14d7cdde6cf8144e84173445c3916263b3a4e7a505cb07603f25c”. This way we can ship the pypi.org metadata with pip and 3rd parties can install their own TUF metadata dirs and there is no configuration required