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==--