[Catalog-sig] Use user-specific site-packages by default?
Jesse Noller
jnoller at gmail.com
Tue Feb 5 14:05:58 CET 2013
On Feb 5, 2013, at 8:02 AM, Holger Krekel <holger.krekel at gmail.com> wrote:
> On Tue, Feb 5, 2013 at 1:51 PM, Donald Stufft <donald.stufft at gmail.com> wrote:
>> On Tuesday, February 5, 2013 at 5:16 AM, Lennart Regebro wrote:
>>> 1. Packages should only be installed from the given package indexes.
>>> No scraping of websites as at least easy_install/buildout does, no
>>> downloading from external download links. A deprecation period for
>>> this of a couple of months, to give package authors the chance to
>>> upload their packages is probably necessary.
>>
>> PyPI will need to change for this to happen realistically if I recall. There is a
>> hard limit on how large of a distribution can be uploaded to PyPI and there
>> are, if I recall, valid distributions which are larger than that.
>>
>>
>> Personally I want the installers to only install from PyPI so my suggestion
>> if this is something that (the proverbial) we want to do, PyPI should gain
>> some notion of a soft limit for distribution upload (to prevent against
>> DoS) with the ability to increase that size limit for specific projects who
>> can file a ticket w/ PyPI to have their limit increased.
>
> Dropping the crawling over external pages needs _much_ more than just a few months deprecation warnings, rather years. There are many packages out there, and it would break people's installations. As a random example, look at http://pypi.python.org/simple/lockfile/ - it has its last release in 2010 and 74K downloads from the 0.9 download url (going to code.google.com).
>
> I certainly agree, though, that the current client-side crawling is a nuisance and makes for unreliability of installation procedures. I think we should move the crawling to the server side and cache packages. I am currently working on a prototype which does this (and a few other niceties). It allows to keep all installers and packages working nicely, serving all packages from one central place (cached on demand currently but that is a policy issue).
>
> best,
> holger
Derived from the current pypi code base?
>
>> _______________________________________________
>> Catalog-SIG mailing list
>> Catalog-SIG at python.org
>> http://mail.python.org/mailman/listinfo/catalog-sig
>
> _______________________________________________
> Catalog-SIG mailing list
> Catalog-SIG at python.org
> http://mail.python.org/mailman/listinfo/catalog-sig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20130205/e5fe12a9/attachment.html>
More information about the Catalog-SIG
mailing list