Le nombre de téléchargements de PyPi semble irréaliste

Question

J'ai mis un paquet sur PyPi pour la première fois il y a environ 2 mois, et nous avons fait quelques mises à jour depuis. J'ai remarqué cette semaine l'enregistrement du nombre de téléchargements, et j'ai été surpris de voir qu'il avait été téléchargé des centaines de fois. Au cours des jours suivants, j'ai été encore plus surpris de voir le nombre de téléchargements augmenter de plusieurs centaines de fois. par jour même s'il s'agit d'une boîte à outils de tests statistiques de niche. En particulier, les anciennes versions du paquet continuent d'être téléchargées, parfois à des taux plus élevés que la version la plus récente.

Qu'est-ce qui se passe ici ?

Y a-t-il un bug dans le comptage des téléchargements de PyPi, ou y a-t-il une abondance de crawlers qui s'emparent du code source ouvert (comme le mien) ?

Answer 1

Il s'agit d'une vieille question, mais j'ai remarqué la même chose à propos d'un paquet que j'ai sur PyPI et j'ai fait des recherches supplémentaires. Il s'avère que PyPI conserve des informations raisonnablement détaillées télécharger les statistiques y compris les agents utilisateurs (apparemment légèrement anonymes). À partir de cela, il est apparu que la plupart des personnes téléchargeant mon paquet étaient des choses comme "z3c.pypimirror/1.0.15.1" et "pep381client/1.5" (PEP 381 décrit une infrastructure de miroir pour PyPI).

J'ai écrit un rapide script pour tout comptabiliser, d'abord en les incluant tous, puis en excluant les bots les plus évidents, et il s'avère que littéralement 99% de l'activité de téléchargement de mon paquet a été causée par les robots miroirs : 14 335 téléchargements au total, contre seulement 146 téléchargements avec les robots filtrés. Et ce chiffre ne tient pas compte des robots les plus évidents, il est donc probablement encore surestimé.

Il semble que la principale raison pour laquelle PyPI a besoin de miroirs est qu'il en a.

Answer 2

En commençant par la déclaration résumée de Cairnarvon :

"On dirait que la principale raison pour laquelle PyPI a besoin de miroirs est qu'elle en a."

Je modifierais légèrement ceci :

C'est peut-être plus le chemin PyPI fonctionne réellement et doit donc être mis en miroir, ce qui pourrait contribuer à ajouter un bit supplémentaire (ou deux :-) à l'image de marque de l'entreprise. réel trafic.

Pour le moment, je pense que vous DEVEZ interagir avec l'index principal pour savoir ce qu'il faut mettre à jour dans votre référentiel. L'état n'est pas simplement accessible par des timestamps sur une hiérarchie de dossiers accessible au public. Donc, la mauvaise chose est que rsync est hors de l'équation. La bonne chose est que vous POUVEZ parler à l'index par le biais d'interfaces JSON, OAuth, XML-RPC ou HTTP.

Pour XML-RPC :

$> python
>>> import xmlrpclib
>>> import pprint
>>> client = xmlrpclib.ServerProxy('http://pypi.python.org/pypi')
>>> client.package_releases('PartitionSets')
['0.1.1']

Pour JSON par exemple. :

$> curl https://pypi.python.org/pypi/PartitionSets/0.1.1/json

S'il y a environ 30.000 paquets hébergés [ 1 ], certains étant téléchargés de 50 000 à 300 000 fois par semaine [ 2 ] (comme distribute, pip, requests, paramiko, lxml, boto, paramike, redis et d'autres) vous avez vraiment besoin de miroirs, au moins du point de vue de l'accessibilité. Imaginez ce que fait un utilisateur lorsque pip install NeedThisPackage échoue : Attendez ? De même, les miroirs PyPI à l'échelle de l'entreprise sont assez courants et agissent comme des proxies pour des réseaux autrement non routables. Enfin, il ne faut pas oublier la merveilleuse vérification des versions multiples rendue possible par virtualenv et ses amis. Ce sont toutes des utilisations légitimes et potentiellement merveilleuses des paquets...

Au final, vous ne savez jamais ce qu'un agent vraiment fait avec un paquet téléchargé : les utilisateurs doivent-ils vraiment l'utiliser ou simplement l'écraser la prochaine fois ? et après tout, les auteurs de paquets devraient se soucier davantage de nombre et nature des utilisations que le pur nombre d'utilisateurs potentiels ;-)

---

Réf : Les chiffres estimés proviennent de https://pypi.python.org/pypi (29303 paquets) et http://pypi-ranking.info/week (pour les chiffres hebdomadaires, demandés le 2013-03-23).

Answer 3

Il faut également tenir compte du fait que virtualenv est de plus en plus populaire. Si votre paquet est quelque chose comme une bibliothèque de base que les gens utilisent dans plusieurs de leurs projets, ils vont généralement le télécharger plusieurs fois.

Considérons qu'un utilisateur unique a 5 projets dans lesquels il utilise votre paquet et chacun vit dans son propre virtualenv. En utilisant pip pour répondre aux exigences, votre paquet est déjà téléchargé 5 fois de cette façon. Ensuite, ces projets peuvent être installés sur différentes machines, comme le bureau, la maison et les ordinateurs portables, sans compter qu'il peut y avoir un serveur de transit et un serveur actif dans le cas d'une application web. En résumé, vous vous retrouvez avec de nombreux téléchargements par une seule personne.

Juste une idée... peut-être que votre paquet est simplement bon ;)

Answer 4

Hypothèse : Les outils d'IC comme Travis CI et Appveyor contribuent aussi beaucoup. Cela pourrait signifier que chaque commit/push conduit à la construction d'un paquet et à l'installation de tout ce qui se trouve dans le fichier requirements.txt.