저번에 Python 패키지의 취약점 데이터베이스를 조사하던 중 거기에 있는 일부 패키지 버전이 Python 표준을 따르지 않기 때문에 쉽게 구문 분석하고 다른 버전 문자열과 비교할 수 없다는 것을 깨달았습니다. Python 버전 관리 - 이전 PEP 440 또는 이를 대체한 버전 지정자 사양입니다. 그래서 나는 이것이 얼마나 흔한 일인지 궁금해하기 시작했습니다. Python 패키지 색인에서 실제로 유효한 버전이 있는 패키지는 몇 개입니까?

분명한 대답은: 가서 확인해 보세요. 그래서 새로운 가상 환경을 만들고, 요청을 다운로드하고, 말 그대로 모든 패키지에서 사용되는 모든 버전 문자열에 대해 PyPI API를 쿼리하는 다중 처리 스크립트를 작성했습니다. 모든 코어에서 실행하는 데에도 몇 시간이 걸렸지만 작업이 끝날 무렵에는 깔끔한 SQLite 데이터베이스에 저장된 545,018개 패키지에서 6,057,703개 이상의 버전 문자열을 검색했습니다. Kaggle에서 찾을 수 있습니다.

다음은 구문 분석이었습니다. 규정 준수를 위해 버전 문자열의 유효성을 검사하겠다고 약속한 두 개의 라이브러리를 찾았습니다.

• pepver: "PEP-440 버전 구문 분석, 해석 및 조작"
• parver: "parver는 PEP 440 버전 번호의 구문 분석 및 조작을 허용합니다"

공평하게 말하면 이 두 가지 모두 현재 교체된 PEP-440을 고수하므로 특히 비준수로 표시된 문자열을 볼 때 이를 명심하겠습니다.

두 시간 동안 집중적인 다중 처리를 수행한 후 문자열이 이 두 패키지(Kaggle에서도 마찬가지)로 성공적으로 구문 분석되었는지 여부를 나타내는 두 개의 부울 열로 데이터베이스를 업데이트했습니다.

결과

내가 조사한 내용을 빠르게 요약하려면:

• 6,057,703개의 버전 문자열 중 5,542개(0.09%)에 결함이 있는 것으로 나타났습니다.

• 545,018개 패키지 중 1,285개(0.24%)에 결함이 있는 버전 문자열이 하나 이상 있습니다.

전반적으로 저장소 상태는 꽤 건강한 것 같습니다! 두 라이브러리 모두에서 잘못된 버전 문자열이 발견되었습니다. 일부는 단순히 비표준 방식으로 접미사를 사용하지만 전체적으로는 의미론적 버전 관리 패러다임을 따르는 반면 다른 일부는 단지 커밋 해시 또는 단어와 숫자로 구성된 문자열입니다.

두 도서관의 의견이 일치하지 않는 경우가 더 흥미롭습니다. pepver는 검증하지 않지만 parver는 검증하는 것들입니다:

0.0.2.R
0.0.2.R3
0.0.2.R4
0.0.2.R5
0.0.2.R6
0.0.2.R7

이 경우에는 페버가 잘못되었다고 말하고 싶습니다. PEP440 및 현재 버전 관리 규칙에 따라 r은 출시 후 태그에 허용되는 철자이며(post로 표준화됨) 문자는 대소문자를 구분하지 않습니다. 따라서 0.0.2.R3은 0.0.2.post3으로 정규화되어 완벽하게 합법적입니다.

그동안 pepver는 인정하지만 parver는 인정하지 않는 임의의 버전 샘플이 있습니다.

0.0.1dev-20141025
1.5.0-dev-618
0.3.4.dev.20180830
1.15.0-dev-1552
1.4.0-dev-510
0.0.9.dev-20121012
0.2dev-20101203
0.3.4.dev.20180905
1.15.0-dev-1606
0.2.1dev-20110627
1.12.0-dev-1379
1.1.1-dev-275
1.3.1-dev-427

모두 dev 접미사 뒤에 구분 기호와 함께 다른 숫자(때때로 날짜)를 사용하는 경향이 있다는 공통점이 있습니다. 이 경우 사양에서는 구분 기호를 허용하지 않으므로 이는 실제로 잘못된 것입니다. 그래서 다시 parver가 옳은 것 같습니다.

어쨌든 그것은 나의 원래 호기심을 거의 만족시켰고 대부분의 경우 버전을 구문 분석하고 비교하는 표준 방법으로 충분하다는 것을 확신했습니다. 비표준 버전에서도 편차가 최소화되어 주문을 식별하는 것이 매우 쉬운 경우가 많습니다. 그럼에도 불구하고 공식 버전 관리의 모든 단점을 알고 언제 이를 신뢰할 수 있는지 또는 의존할 수 없는지를 아는 것은 유용합니다.