01
모드마다 답하는 질문이 다릅니다
정규화는 표기를 검사하고, 정렬은 버전 우선순위를 비교합니다. 조건 검사는 원래 순서를 유지합니다. 정렬에서 동등한 버전의 순서는 바뀌지 않으며 잘못된 행은 마지막에 모아 원래 행 번호와 함께 표시합니다.
개발자 도구
PEP 440 버전 비교Python 릴리스의 순서와 조건 확인
한 줄에 버전 하나를 입력하고 정규화, 정렬 또는 쉼표로 연결한 조건 검사를 선택하세요.
PEP 440 버전 비교
버전 목록 (한 줄에 하나)
검사 보고서
입력하거나 예시를 불러오세요.
입력은 이 브라우저에서 처리되며 서버로 전송되지 않습니다.
옵션
쉼표는 AND입니다. 빈 조건에는 경계가 없습니다. ~= == != <= >= < > === 지원. .*는 == 또는 !=의 릴리스 접두사에만 사용합니다.
비어 있지 않은 행 1,000개. UTF-16 단위로 행 256, 조건 2,048, 목록 전체 100,000까지. 빈 행은 건너뛰고 입력은 보존합니다.
현재 후보 검사 중…
PEP 440 버전 비교는 새 릴리스가 의존성 후보에서 빠지는 이유를 확인할 때 유용합니다. 버전 표기가 유효한지, 어떤 버전이 더 큰지, 조건에 맞는지는 서로 다른 질문입니다. 보고서는 이 결과를 나누어 보여 줍니다.
Python에서는 1.0과 1.0.0이 같은 순위를 가질 수 있지만 정규화 결과의 자릿수는 유지됩니다. 문자열 정렬만으로는 놓치기 쉬운 epoch, dev, post와 로컬 태그도 각각 확인할 수 있습니다.
PEP 440 버전 비교가 필요한 이유
원래 표기와 정규화 결과를 함께 확인
PEP 440 버전 비교는 v01.1을 1.1로 바꾸어 표시하면서 원래 입력을 남깁니다. 행을 펼치면 epoch, 릴리스 번호, pre, post, dev, local을 확인할 수 있어 어떤 부분이 달라졌는지 추적하기 쉽습니다.
출시 전 버전이 제외되는 이유 표시
자동 정책은 전체 목록에서 모든 조건에 맞는 후보를 먼저 찾습니다. 정식판이나 후속 릴리스가 있으면 이를 우선하며, 그런 후보가 없을 때 조건을 만족하는 출시 전 버전을 허용합니다. 목록에 한 줄을 더한 것만으로 결과가 달라질 수 있습니다.
결과를 읽기 전에 확인할 세 가지
02
자동 정책은 후보 전체로 시험하세요
조건을 만족하는 정식판을 지우면 출시 전 후보가 다시 허용되는지 확인할 수 있습니다. 포함을 선택해도 숫자 경계는 그대로입니다. 1.0rc1은 1.0보다 작으므로 >=1.0을 만족하지 않습니다.
03
변경 후 최신 결과를 사용하세요
자동 검사는 입력이 멈춘 뒤 350ms 후 실행합니다. 끄면 실행 버튼이나 Ctrl/Cmd+Enter를 쓸 수 있습니다. 수정 직후에는 이전 결과 내보내기가 비활성화됩니다. 예시와 비우기는 미리 보기 후 적용하며 한 번 되돌릴 수 있습니다.
표기, 순서, 후보 자격을 따로 검사
원본을 보존하는 버전 정규화
v 접두사, 숫자의 앞자리 0, alpha나 preview 같은 별칭, 로컬 구분자를 표준 형태로 정리합니다. 릴리스 숫자 구간의 개수는 유지하므로 1.0.0은 그대로 표시됩니다. 비교할 때의 0 보충과는 다른 동작입니다.
Python 규칙에 따른 정렬
epoch를 먼저 비교한 뒤 릴리스 숫자와 개발판, alpha, beta, rc, 정식판, post 순서를 판정합니다. 로컬 구간의 숫자는 정수로 비교하며 JavaScript의 안전 정수 범위를 넘는 값도 반올림하지 않습니다.
여러 버전 지정자를 동시에 적용
~=, ==, !=, <=, >=, <, >, ===를 지원합니다. 쉼표는 AND이며 ==1.4.* 같은 릴리스 접두사 조건도 사용할 수 있습니다. 조건 불일치와 출시 전 정책에 따른 제외를 구분합니다.
오류가 있는 행도 보고서에 보존
잘못된 버전은 해당 행만 오류로 남기고 다른 행의 계산은 계속합니다. 잘못된 조건은 전체 실행을 중단합니다. 화면에서는 50개씩 더 표시하지만 JSON에는 처리한 모든 행과 오류 코드가 포함됩니다.
지원 범위와 실제 제한
- 버전과 조건만 입력
- 패키지 이름, extras, 환경 마커, requirements 파일, URL, 잠금 파일을 해석하지 않습니다. PyPI 조회, 설치, 의존성 해결, 프로젝트 수정, 다음 버전 생성도 하지 않습니다. 일치 결과가 API 호환성을 의미하지는 않습니다.
- 다른 생태계의 범위 문법은 제외
- ^1.2, 단독 ~1.2, OR, 하이픈 범위는 오류입니다. 호환 릴리스 조건은 ~=1.2처럼 씁니다. 빈 조건은 숫자 경계를 두지 않지만 출시 전 정책은 적용됩니다. 쉼표 사이의 빈 항목은 무시합니다.
- 로컬 버전의 비교 규칙
- 로컬 태그는 정렬에 영향을 줍니다. 공개 버전만 지정한 ==와 !=는 후보의 local을 무시하지만 local을 명시한 동등 조건은 그 값도 비교합니다. >=1.0+linux와 ~=1.0+linux는 유효하지 않습니다.
- ===도 후보 검증을 생략하지 않음
- ===는 정규화된 후보 표기를 비교하며 끝의 0을 보충해 같다고 처리하지 않습니다. 후보는 유효한 PEP 버전이어야 합니다. ===legacy를 써도 legacy 행은 오류로 남으며 오래된 설치기의 임의 문자열 처리를 흉내 내지 않습니다.
- 자동 판단은 현재 목록에 한정
- dev는 출시 전 버전에 포함됩니다. 긍정 조건에서 출시 전 버전을 명시하면 허용할 수 있고, 나머지는 모든 조건에 맞는 정식 후보가 있는지에 따라 대체 후보를 선택합니다. 이미 설치된 패키지나 다른 배포판은 확인하지 않습니다.
- 명시적인 입력 한도
- 비어 있지 않은 행은 1,000개, 행마다 256, 조건은 2,048, 전체 목록은 100,000 UTF-16 단위까지입니다. 이는 도구의 처리 한도입니다. 빈 행은 건너뛰되 물리 행 번호를 남기며 중복을 없애거나 정규화 결과로 입력을 덮어쓰지 않습니다.
PEP 440 버전 비교 질문
Python 의존성 조건의 ~=는 무슨 뜻인가요?
하한과 릴리스 접두사 조건을 함께 적용합니다. ~=1.4는 1.4부터 1.* 범위이고 ~=1.4.0은 1.4.*에 한정됩니다. ~=1처럼 숫자 구간이 하나뿐인 조건은 잘못된 형식입니다. 출시 전 버전 허용 여부는 별도로 판단합니다.
출시 전 버전이 혼자 있을 때만 일치하는 이유는 무엇인가요?
자동 필터는 맞는 정식 후보가 없을 때 출시 전 버전으로 대체할 수 있습니다. 조건에 맞는 정식판이나 post 버전을 추가하면 목록 전체의 판단이 바뀝니다. 포함으로 가능한 후보를 모두 보거나 제외로 출시 전 후보를 항상 거부할 수 있습니다.
공개 버전과 로컬 버전은 어떻게 정렬되나요?
공개 부분이 같으면 로컬 태그가 붙은 버전이 뒤에 옵니다. 예를 들어 1.0 < 1.0+abc입니다. 로컬 숫자 구간은 문자 구간보다 뒤에 오며 동등한 값은 입력 순서를 유지합니다. SemVer 빌드 메타데이터와는 다른 규칙입니다.
조건에 로컬 태그를 넣어도 되나요?
==1.0+linux.1 또는 !=1.0+linux.1은 가능합니다. >=와 ~=에는 로컬 태그를 넣을 수 없습니다. ==1.0은 특정 로컬 빌드를 요구하지 않으므로 1.0+linux.1도 일치할 수 있습니다.
Python에서 버전 번호를 비교하려면 무엇을 쓰나요?
PEP 규칙을 따르는 비교에는 packaging.version.Version을 사용할 수 있습니다. 이 페이지는 packaging 26.0과 결과를 대조합니다. 일반 문자열 비교는 1.10과 1.9를 잘못 정렬할 수 있고 다른 규격은 epoch나 post를 해석하지 못할 수 있습니다.
pre나 post 뒤에 .*를 붙일 수 있나요?
==1.0.*는 유효한 릴리스 접두사 조건이지만 ==1.0rc1.*와 ==1.0.post1.*는 잘못된 형식입니다. 접미사를 제한하려면 정확한 동등 조건이나 상하한을 쓰세요. 접두사 일치도 출시 전 정책의 적용을 받습니다.
예상과 다른 버전 결과인가요?
실제 릴리스 후보를 다시 확인
PEP 440 버전 비교에 조사 중인 목록과 조건을 넣고 오류 행과 자동 정책 설명을 살펴보세요. 최신 보고서는 원래 표기와 정규화 값, 사용한 조건을 함께 남겨 판단을 재현할 수 있게 합니다.