[Distutils] PEP470, backward compat is a ...

[Donald Stufft]

On May 17, 2014, at 1:36 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 16 May 2014 21:20, Donald Stufft <donald at stufft.io> wrote:
>> However that being said, a significant portion of that 7% has only a few
>> (sometimes only 1) old releases hosted externally. Often times when I've
>> pointed this out to authors they didn't even realize it and they had just
>> forgotten to call ``setup.py upload``. Finally of the projects left a lot of
>> them are very old (I've found some that were last released in 2003). A lot of
>> them do not work with any modern version of Python and some of them do not
>> even have a ``setup.py`` at all and thus are not installable at all. These
>> are all issues that my processing didn't attempt to classify because I wanted
>> to remove my personal bias from the numbers, but the simple fact is that while
>> the maximum amount may be 7%, the actual amount is going to be far far less
>> than that.
> 
> From the spot checks I did on your numbers the other day (by looking
> at the simple API entries for affected projects), I think it's worth
> rescanning the externally hosted packages to at least check for those
> where "latest release is hosted on PyPI" holds true. pyOpenSSL appears
> on the list, for example, but that's just due to 0.11 never being
> uploaded - everything else (including the 3 subsequent releases) is
> hosted directly on PyPI.
> 
> For those projects, there's a potential migration path where switching
> to "pypi-only" would disallow adding *new* external links, but
> grandfather in the inclusion of *existing* external links. "Delete
> external links" could then be a separate button that they can choose
> whether or not to push. That button should carry a clear warning that
> it *may* break automated installation for users that have pinned the
> old versions, and leave it up to the project maintainer to decide
> which they want to do.
> 
> The other item that would be potentially useful to discussion of the
> affected projects is to categorise them by their "last updated" year.
> We may find that the numbers get low enough where it *is* practical to
> consider contacting each of them directly (rather than solely via mass
> email from PyPI)
> 
> Not wanting to inject your biases into the numbers is admirable, but
> making decisions based on numbers that are known to be inaccurate
> isn't a good idea either :)

Well yea, but the question is as always, what numbers are accurate ;)

I’m planning on sorting out which of the files have (or don’t) have their
latest versions on PyPI. I haven’t done it yet because parsing that
info out of the filename is non obvious and I have to figure out how.

Good news is I don’t have to recrawl because I have all the raw data :D

-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20140517/35e6b4ec/attachment.sig>