Re: PyPI and debian/watch
On Feb 04, 2015, at 08:08 AM, Donald Stufft wrote:
>If it gets implemented it'll live at /uscan/ because it exists primarily to
>work around the deficiencies that exist in uscan (Particularly the dificulty
>in ignoring url fragments). Everyone else should just use the URLs at /simple/
>which most systems use with no problem because they can parse the URLs and
>ignore the URL fragments (or use them for verifying the hash if need be).
I'll just note that I've found the fragments inconvenient in other settings
too. They aren't very user friendly since (IMHO) they add noise that users
cutting and pasting urls generally don't care about. They also "feel" odd in
that the md5 checksum doesn't fit what I think as a typical fragment.
Traditionally, they are used to point to an anchor (sub-resource) within the
parent resource. That's not the case here.
http://en.wikipedia.org/wiki/Fragment_identifier
has this to say:
"""
Several proposals have been made for fragment identifiers for use with plain
text documents (which cannot store anchor metadata), or to refer to locations
within HTML documents in which the author has not used anchor tags:
As of September 2012 the Media Fragments URI 1.0 (basic) is a W3C
Recommendation.[12]
The Python Package Index appends the MD5 hash of a file to the URL as a
fragment identifier.[13] If MD5 were unbroken (it is a broken hash function),
it could be used to ensure the integrity of the package.
https://pypi.python.org ... zodbbrowser-0.3.1.tar.gz#md5=38dc89f294b24691d3f0d893ed3c119c
"""
So even without the uscan incompatibility (which is just one of the two
factors leading to noisy d/watch file), I think there's some value in
fragment-less URLs. I understand the checksum isn't being used
cryptographically here, but maybe thinking ahead to the use of more secure
algorithms in the future can lead to a more flexible design:
Legacy (if it indeed needs to be kept for backward compatibility):
/simple/foo-x.y.z#md5=blah
then:
/simple/plain/foo-x.y.z
/simple/sha256/foo-x.y.z#sha256=blah
etc.
Cheers,
-Barry
Reply to: