Re: V4 Pre-PEP: transition to release-file hosting on PYPI

Carl Meyer <[email protected]> Mon, 18 Mar 2013 17:48:52 -0700
Newsgroups gmane.comp.python.catalog
Message-ID <[email protected]>
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============2123705291==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enigB85B5DE9C7C19AEC6B65A704"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigB85B5DE9C7C19AEC6B65A704
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Richard,

On 03/18/2013 12:02 PM, Richard Jones wrote:
> Some suggested edits; I'm otherwise quite happy with the current draft.=

>=20
> On 15 March 2013 02:29, holger krekel <[email protected]> wrote:
>> History and motivations for external hosting
>=20
> Could we please have a reference to the Package Index "API"* here?

Added.

>> Today, most packages released on PyPI host their release files on
>> PyPI, but a small percentage (XXX need updated data) rely on
>> external hosting.
>=20
> The above should probably be re-worded since "rely" is loaded and we
> don't necessarily know the motivation for projects using external
> links. The important numbers though are:
>=20
> projects with any external only links: 2581
> projects with only external only links: 1332
> total projects: 29117
>=20
> Whether the projects with links that also have hosted files (ie. the
> 1249 project difference between those numbers) *rely* on us retaining
> the external links facility is unknown.

Done: updated to include the latest numbers, re-worded to remove the
word "rely", and added a link to the data and analysis tool source code
at https://github.com/dstufft/pypi.linkcheck

>> Hosting modes
>> -------------
>>
>> The foundation of the first transition phase is the introduction of
>> three "modes" of PyPI hosting for a package, affecting which links are=

>> generated for the ``simple/`` index.  These modes are implemented
>> without requiring changes to installation tools via changes to the
>> algorithm for generating the machine-readable ``simple/`` index.
>>
>> The modes are:
>>
>> - ``pypi-scrape-crawl``: no change from the current situation of
>>   generating machine-readable links for installation tools, as
>>   outlined in the history_.
>>
>> - ``pypi-scrape``: for a package in this mode, links to be added to
>>   the ``simple/`` index are still scraped from package
>>   metadata. However, the "Home-page" and "Download-url" links are
>>   given ``rel=3Dext-homepage`` and ``rel=3Dext-download`` attributes
>>   instead of ``rel=3Dhomepage`` and ``rel=3Ddownload``. The effect of =
this
>>   (with no change in installation tools necessary) is that these links=

>>   will not be followed and scraped for further candidate links by pres=
ent-day
>>   installation tools: only installable files directly hosted from PYPI=
 or
>>   linked directly from PyPI metadata will be considered for installati=
on.
>>   Installation tools MAY evolve to offer an option to use the new
>>   rel-attribution to crawl external pages but MUST NOT default to it.
>=20
> I'd just like to confirm that the rel=3D"download" / rel=3D"ext-downloa=
d"
> switch will not affect the installability of distribution downloads
> linked directly by download_url.

It won't. The rel attribute impacts only whether a link to a non-archive
(HTML) resource is scraped for further links, it doesn't impact a direct
archive link.

>> - ``pypi-explicit``: for a package in this mode, only links to release=

>>   files uploaded to PyPI, and external links to release files
>>   explicitly nominated by the package owner (via a new interface
>>   exposed by PyPI) will be added to the ``simple/`` index.
>=20
> The bracketed bit there needs to be emphasised (ie. not just a
> bracketed afterthought) as it changes the current packaging user
> experience considerably for those who wish to remain externally
> hosting files.

Done, and added the requirement that external links must include hashes,
as we just discussed in person.

All of these updates are in https://bitbucket.org/hpk42/pep-pypi - feel
free to sync to python.org at your leisure.

Carl


--------------enigB85B5DE9C7C19AEC6B65A704
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAlFHtfQACgkQ8W4rlRKtE2dj+gCeMfQOTgzLBfrJq0BYIRyVRLVd
vRcAnjyo1xhinN+ugMKfMSaWX09a2X30
=sNiZ
-----END PGP SIGNATURE-----

--------------enigB85B5DE9C7C19AEC6B65A704--

--===============2123705291==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Catalog-SIG mailing list
[email protected]
http://mail.python.org/mailman/listinfo/catalog-sig

--===============2123705291==--