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 :) Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
