PEP 627 – 설치된 프로젝트 기록
- Author:
- Petr Viktorin <encukou at gmail.com>
- BDFL-Delegate:
- Paul Moore <p.f.moore at gmail.com>
- Discussions-To:
- Discourse thread
- Status:
- Final
- Type:
- Standards Track
- Topic:
- Packaging
- Created:
- 15-Jul-2020
- Resolution:
- Discourse message
번역·라이선스 안내
이 비공식 한국어 번역은 원문 Copyright 절의 Public Domain or CC0-1.0, whichever is more permissive 조건에 따라 제공합니다. 원저자와 공식 원문은 그대로 표시합니다. 수정되지 않은 기준 원문 · 공식 최신판
초록
이 PEP는 PEP 376 (설치된 Python 배포본 데이터베이스)를 명확히 하고 갱신하여 상호 운용성 표준으로 다시 작성합니다. 이 PEP는 표준의 공식 위치를 Python 패키징 관리 기구(Python Packaging Authority, PyPA)의 표준 저장소로 옮기고, 표준을 변경하기 위한 지침을 마련합니다.
설치된 .dist-info 디렉터리의 두 파일, 즉 RECORD (PEP 376에서는 필수로 명시하지만 “시스템 패키지”에서는 생략할 수 있다고 제안하는 파일)와 INSTALLER를 선택 사항으로 합니다.
동기
Python 패키징은 특정 도구(Setuptools와 pip)에 의존하던 방식에서 여러 도구로 이루어진 생태계와 도구에 구애받지 않는 상호 운용성 표준으로 옮겨 가고 있습니다.
PEP 376은 상호 운용성 표준으로 작성되지 않았습니다. 이 문서는 특정 도구와 라이브러리의 구현 세부 사항을 설명하며, 명세가 불충분하여 구현에 따라 정의되는 동작의 여지를 많이 남깁니다.
이 제안은 PEP 376에서 표준을 “정제”하고, 이를 명확히 하며, 도구에 구애받지 않도록 다시 작성하려는 것입니다.
이 PEP의 목표는 반드시 완벽한 표준이 아니라 더 나은 표준을 마련하는 것입니다. 일부 문제는 추후 명확히 하도록 남겨 둡니다.
근거의 변경
PEP 376의 근거는 두 가지 문제에 초점을 맞춥니다:
- 프로젝트를 설치하는 방법이 너무 많아서 상호 운용이 어렵습니다.
- 설치된 배포본에 관한 정보를 얻는 API가 없습니다.
새 문서는 설치된 프로젝트에 관한 정보의 디스크상 형식에만 초점을 맞춥니다. 이 정보를 설치, 제거 또는 조회하는 API를 제공하는 일은 도구가 구현하도록 남겨 둡니다.
표준 및 변경 절차
설치된 프로젝트 기록(이전 명칭은 설치된 Python 배포 데이터베이스)의 공식 표준은 packaging.python.org에 있는 documentation입니다. 문서에 대한 모든 변경(사소한 문구나 조판 수정은 제외)은 PEP 절차를 거쳐야 합니다.
이 문서는 규범적입니다(이해를 돕기 위한 예시를 포함합니다). 이 PEP처럼 문서를 변경하는 PEP에는 근거나 호환성 고려 사항처럼 시간이 지나면 낡을 것으로 예상되는 추가 정보가 담깁니다.
제안된 표준은 이 PEP와 함께 packaging.python.org에 풀 리퀘스트로 제출됩니다.
변경 사항과 그 근거
“Recording installed projects”로 이름 변경
표준의 이름을 설치된 Python 배포 데이터베이스에서 설치된 프로젝트 기록으로 변경합니다.
디스크의 알려진 위치에 파일을 두는 것을 “데이터베이스”로 볼 수도 있지만, 대부분의 사람들이 이 용어를 들을 때 떠올리는 것은 그런 것이 아닙니다. PyPA는 설치된 배포 기록이라는 제목 아래에서 PEP 376에 링크하고 있습니다.
PyPA 용어집은 “배포본(Distribution)”(또는 Linux 배포판 등과 혼동하지 않도록 “배포 패키지(Distribution Package)”)을 “버전이 지정된 아카이브 파일 […]”로 정의합니다. 아카이브 파일이 아닌 다른 방법으로 Python 코드를 설치할 수도 있으므로, 이 문서는 “설치된 배포본” 대신 “설치된 프로젝트”라는 용어를 사용합니다.
구현 세부 사항의 제거
도구 및 라이브러리에 특화된 세부 사항은 모두 제거되었습니다. 프로젝트가 설치되는 방식에 관한 메커니즘도 제외되었습니다. 이 문서는 최종 상태에 초점을 맞춥니다. 한 가지 예외는 설치 제거 알고리즘의 개요로, RECORD 파일의 목적을 더 잘 설명하기 위해 포함되었습니다.
setuptools와 distutils에 특화된 형식인 .egg-info와 .egg에 대한 언급은 제외되었습니다.
추가 파일의 명시적 허용
.dist-info 디렉터리에는 명세에 규정되지 않은 파일이 포함될 수 있습니다. 현재 도구들은 이미 그렇게 하고 있습니다.
명세의 한 참고 사항은 휠의 .dist-info 디렉터리에 있는 파일을 언급합니다. 현재 도구들은 이 파일들을 설치된 .dist-info로 복사하며, 이는 향후 표준화 작업에서 염두에 두어야 할 점입니다.
RECORD 파일에 관한 명확화
CSV 방언은 Python csv 모듈의 기본값으로 지정합니다. 이로써 파일 이름에 포함된 큰따옴표와 줄 종결자 처리에 관한 경계 사례가 해결됩니다.
RECORD에 있는 상대 경로의 “기준”은 도구별 --install-lib 및 --prefix 옵션이 아니라 .dist-info 디렉터리를 기준으로 규정됩니다.
이제 해시와 크기 필드는 모두 선택 사항입니다(.pyc, .pyo, RECORD뿐만 아니라 모든 파일에 해당합니다). *.pyc와 RECORD 자체를 제외하고는 이 필드들을 생략하지 않는 것이 좋습니다. (PEP 376은 무엇이 선택 사항이었는지 불분명하다는 점에 유의하십시오. 문자 그대로 받아들이면 본문과 예제가 서로 모순됩니다. 그럼에도 불구하고 “두 필드 모두 선택 사항”이라는 것은 PEP 376에 대한 합리적인 해석입니다. 대안은 해시와 크기 없이 기록할 수 있는 파일을 권고가 아니라 의무로 정하고, 새로운 사용 사례가 생길 때마다 그 목록을 갱신하는 것입니다.)
새 명세는 RECORD 파일이 이제 설치된 프로젝트의 모든 파일을 포함해야 한다고 명시합니다(.pyc 파일에 대한 예외는 유지됩니다). 도구는 설치 제거에 RECORD를 사용하므로, 불완전한 파일 목록은 사용자 환경에 고아 파일을 남길 수 있습니다. 반면에, 이는 전체 파일 목록을 알 수 없는 경우 일부 파일의 해시만 기록할 방법이 없다는 뜻이기도 합니다.
이 파일의 주된 목적과 내용을 명확히 하기 위해 설치 제거 알고리즘의 개요가 포함되어 있습니다.
도구는 RECORD 파일이 없는 프로젝트를 제거하거나 삭제해서는 안 됩니다(Linux 배포판의 시스템 패키지 관리자처럼 외부 정보가 있는 경우는 예외입니다).
Windows에서 RECORD의 파일 경로는 / 또는 \ 중 어느 것으로도 구분될 수 있습니다. PEP 376은 이 점이 불분명했습니다. 한 곳에서는 슬래시를 의무화하면서도, Windows 전용 예제에서는 백슬래시를 보여 줍니다.
선택 사항인 RECORD 파일
RECORD 파일은 선택 사항이 되었습니다. 모든 도구가 설치된 파일 목록을 Python 고유의 형식으로 쉽게 생성할 수 있는 것은 아닙니다.
특히 Linux 시스템 패키징 시스템으로 프로젝트를 설치한 경우에는 RECORD 파일이 필요하지 않습니다. 이런 시스템에는 파일을 추적하고, 제거하고, 무결성을 검사하는 자체 방법이 있기 때문입니다. RECORD 파일을 디스크 및 시스템 패키지 데이터베이스와 동기화된 상태로 유지해야 한다면 지나치게 취약해질 것이며, 실제와 일치하지 않는 RECORD 파일보다는 RECORD 파일이 없는 편이 낫습니다.
(밝혀 두자면, 이 PEP의 작성자는 Fedora Linux 배포판에서 활동하는 RPM 패키저입니다.)
선택 사항인 INSTALLER 파일
INSTALLER 파일도 선택 사항이 되었으며, 정보 제공 목적으로만 사용하도록 규정되었습니다. 이 파일은 여전히 설치 프로그램의 이름을 담은 한 줄짜리 텍스트 파일입니다.
이 파일은 원래 Python 설치 프로그램(pip)으로 설치한 프로젝트와 다른 패키지 관리자(예: dnf)로 설치한 프로젝트를 구별하기 위해 추가되었습니다. 이 파일을 이용해 pip가 직접 설치하지 않은 패키지를 업데이트하거나 제거하지 못하도록 막으려는 시도가 있었습니다.
우리의 목표는 서로 상호 운용되는 도구를 지원하는 것이며, 어떤 도구가 패키지를 설치했는지를 기준으로 동작을 정하는 것은 이 목표에 어긋납니다.
도구는 설치 프로그램의 이름에 의존하는 대신 기능 감지를 사용해야 합니다. 현재 문서는 Python 도구가 프로젝트를 건드리지 못하게 하는 투박한 방법을 제시합니다. 바로 RECORD 파일을 생략하는 것입니다.
반면에 설치 프로그램의 이름은 사용자에게 힌트를 줄 때 유용할 수 있습니다.
파일의 이러한 새 목적에 맞추어, 새 명세는 INSTALLER에 소문자 식별자로 제한하지 않고 임의의 ASCII 문자열을 허용합니다. 또한 가능하다면 명령줄 명령어를 사용할 것을 권장합니다.
REQUESTED 파일: 명세에서 제거됨
이제 REQUESTED 파일은 도구별 확장으로 간주됩니다.
PEP 376에 따르면 REQUESTED는 다른 프로젝트의 의존성을 충족하기 위해 자동으로 설치된 경우가 아니라, 사용자가 직접 요청하여 프로젝트를 설치했을 때 기록되어야 했습니다. 이 표시 파일이 없는 프로젝트는 더 이상 필요하지 않을 때 제거할 수 있었습니다.
표준이 있는데도 기존의 많은 설치 프로그램(이전 버전의 pip 포함)은 이 파일을 전혀 기록하지 않습니다. “더 이상 필요하지 않을 때 제거해도 되는” 프로젝트와 단지 REQUESTED를 무시하는 도구로 설치되었을 뿐인 프로젝트 사이에는 아무런 구별이 없습니다. 따라서 현재 이 파일은 (도구가 비표준 정보를 추가로 활용할 수 있는 경우가 아니라면) 본래 의도한 목적대로 사용할 수 없습니다.
명확화
가능한 경우 용어(name, version 등)는 기존 명세를 참조하여 뜻을 한정합니다.
보류된 아이디어
이 PEP의 범위를 제한하기 위해 일부 개선 사항은 명시적으로 향후 PEP에 맡깁니다:
RECORD파일의 인코딩.dist-info에 들어갈 수 있는 파일의 제한 또는 네임스페이스 지정- 사용자가 직접 요청하여 설치한 프로젝트와 의존성을 충족하기 위해 설치한 프로젝트의 차이를 표시하여, 후자를 더 이상 필요하지 않을 때 제거할 수 있도록 하는 것
Copyright
This document is placed in the public domain or under the CC0-1.0-Universal license, whichever is more permissive.