On May 17, 2014, at 1:36 AM, Nick Coghlan <[email protected]> wrote:
> On 16 May 2014 21:20, Donald Stufft <[email protected]> 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
