PyPi 다운로드 수가 비현실적으로 보입니다.

PyPi 다운로드 수가 비현실적으로 보입니다.

---

나는 넣어 PyPi에 패키지를 1 ~ 2 개월 전에 처음으로, 그 이후 어떤 버전 업데이트를 만들었습니다. 이번 주에 다운로드 횟수가 기록되는 것을 보았고 수백 번 다운로드 된 것을보고 놀랐습니다. 다음 며칠 동안, 이것이 틈새 통계 테스트 도구 상자 임에도 불구 하고 다운로드 수가 하루에 수백 씩 증가하는 것을보고 더 놀랐습니다 . 특히 이전 버전의 패키지는 최신 버전보다 높은 속도로 계속 다운로드되고 있습니다.

여기서 무슨 일이 일어나고 있습니까?

PyPi의 다운로드 횟수에 버그가 있습니까, 아니면 오픈 소스 코드를 잡는 많은 크롤러가 있습니까 (제대로)?

---

이 시점에서 이것은 일종의 오래된 질문이지만 PyPI에있는 패키지에 대해 동일한 것을 발견하고 추가로 조사했습니다. PyPI 는 (명백하게 약간 익명화 된) 사용자 에이전트를 포함하여 합리적으로 상세한 다운로드 통계를 유지합니다 . 그로부터 내 패키지를 다운로드하는 대부분의 사람들이 "z3c.pypimirror / 1.0.15.1"및 "pep381client / 1.5"와 같은 것임을 알 수있었습니다. (PEP 381은 PyPI의 미러링 인프라를 설명합니다.)

먼저 모든 항목을 포함하고 가장 분명한 봇을 제외 하는 빠른 스크립트 를 작성 했는데 내 패키지 다운로드 활동의 99 % 가 미러 봇에 의해 발생했습니다. 총 14,335 회 다운로드 봇이 필터링 된 다운로드는 146 개뿐입니다. 그리고 그것은 매우 명백한 것을 제외하고 있기 때문에 아마도 과대 평가 일 것입니다.

PyPI에 미러가 필요한 주된 이유는 미러가 있기 때문입니다.

---

Cairnarvon의 요약 진술로 시작 :

"PyPI에 미러가 필요한 주된 이유는 미러가 있기 때문입니다."

나는 이것을 약간 수정합니다.

PyPI가 실제로 작동 하는 방식에 더 가깝기 때문에 미러링되어야하므로 실제 트래픽에 추가 비트 (또는 두 개의 :-)를 제공 할 수 있습니다.

현재로서는 리포지토리에서 무엇을 업데이트해야하는지 알기 위해 메인 인덱스와 상호 작용해야한다고 생각합니다. 상태는 공개적으로 액세스 할 수있는 일부 폴더 계층 구조의 타임 스탬프를 통해 단순히 액세스 할 수 없습니다. 따라서 나쁜 점은 rsync가 방정식에서 벗어났다는 것입니다. 좋은 점은 JSON, OAuth, XML-RPC 또는 HTTP 인터페이스를 통해 색인과 대화 할 수 있다는 것입니다.

XML-RPC의 경우 :

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

예를 들어 JSON의 경우 :

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

약이 있다면. 30.000 패키지 호스팅 [ 1 ] 일부는 일주일에 50.000 ~ 300.000 회 다운로드 됨 [ 2 ] (예 : 배포, pip, 요청, paramiko, lxml, boto, paramike, redis 등) 최소한 접근성 관점에서는 미러가 필요합니다. pip install NeedThisPackage실패 했을 때 사용자가 무엇을하는지 상상해보십시오 . 잠깐만 요? 또한 회사 전체의 PyPI 미러는 라우팅 할 수없는 네트워크의 프록시 역할을하는 매우 일반적입니다. 마지막으로 virtualenv와 친구들을 통해 활성화 된 멋진 멀티 버전 확인을 잊지 마세요. 이것들은 모두 IMO의 합법적이고 잠재적으로 훌륭한 패키지 사용입니다 ...

결국, 당신은 결코 에이전트가 무엇인지 모르는 정말 다운로드 한 패키지와 함께 수행합니다 유무 N 사용자가 정말 사용하거나 그냥 다음을 덮어 ... 그리고 결국, 이럴 패키지 저자는 더 많은 것을 위해 관심을 가져야 번호와 사용의 성격 보다, 순수한 잠재 사용자 수 ;-)

---

Refs : 게스트 번호는 https://pypi.python.org/pypi(29303 패키지) 및 http://pypi-ranking.info/week (주간 번호는 2013 년 3 월 23 일에 요청 됨 )에서 가져온 것 입니다.

---

또한 virtualenv가 점점 인기를 얻고 있음을 고려해야합니다. 패키지가 사람들이 많은 프로젝트에서 사용하는 핵심 라이브러리와 같은 경우 일반적으로 여러 번 다운로드합니다.

단일 사용자가 패키지를 사용하는 5 개의 프로젝트가 있고 각 프로젝트가 자체 가상 환경에 있다고 가정합니다. pip를 사용하여 요구 사항을 충족하면 패키지가 이미 이러한 방식으로 5 번 다운로드됩니다. 그런 다음 이러한 프로젝트는 직장, 가정 및 랩톱 컴퓨터와 같은 다른 컴퓨터에 설정 될 수 있으며 웹 애플리케이션의 경우 스테이징 및 라이브 서버가있을 수 있습니다. 이를 요약하면 한 사람이 많은 다운로드를 받게됩니다.

그냥 생각 해봐요 ... 아마도 당신의 패키지는 단순히 좋은 것입니다. ;)

---

가설 : Travis CI 및 Appveyor와 같은 CI 도구도 상당한 기여를합니다. 각 커밋 / 푸시가 패키지 빌드와 requirements.txt의 모든 항목 설치로 이어진다는 의미 일 수 있습니다.

참고 URL : https://stackoverflow.com/questions/9648015/pypi-download-counts-seem-unrealistic