PEP 650 – Python 프로젝트의 설치 관리자 요구 사항 지정

Author:: Vikram Jayanthi <vikramjayanthi at google.com>, Dustin Ingram <di at python.org>, Brett Cannon <brett at python.org>
Discussions-To:: Discourse thread
Status:: Withdrawn
Type:: Standards Track
Topic:: Packaging
Created:: 16-Jul-2020
Post-History:: 14-Jan-2021

Table of Contents

초록
용어
동기
사양
예
근거
하위 호환성
보안 영향
거부된 아이디어
- 표준화된 잠금 파일
- 설치 백엔드가 가상 환경 생성을 지원하도록 하기
미해결 문제
참고 문헌
Copyright

번역·라이선스 안내

이 비공식 한국어 번역은 원문 Copyright 절의 Public Domain or CC0-1.0, whichever is more permissive 조건에 따라 제공합니다. 원저자와 공식 원문은 그대로 표시합니다. 수정되지 않은 기준 원문 · 공식 최신판

초록

Python 패키지 설치 관리자는 서로 완전히 상호 운용되지 않습니다. pip가 가장 널리 사용되는 설치 관리자이자 사실상의 표준이지만, Poetry 또는 Pipenv 같은 다른 설치 관리자도 특정 워크플로에 최적인 고유 기능을 제공하며 pip의 작동 방식과 직접적으로 일치하지 않기 때문에 인기가 있습니다.

설치 관리자 선택지가 풍부한 것은 특정 요구 사항이 있는 최종 사용자에게는 좋지만, 이들 간의 상호 운용성이 부족하여 잠재적인 모든 설치 관리자를 지원하기가 어렵습니다. 구체적으로, 의존성을 선언하기 위한 표준 요구 사항 파일이 없다는 것은 각 도구의 형식으로 지정된 의존성을 설치하려면 각 도구를 명시적으로 사용해야 한다는 의미입니다. 그렇지 않으면 도구가 요구 사항 파일을 생성해야 하며, 이는 설치 관리자에 잠재적인 정보 손실을 초래할 뿐만 아니라 개발자의 워크플로에 내보내기 단계를 추가합니다.

호환 가능한 설치 관리자를 호출하는 데 사용할 수 있는 표준화된 API를 제공하면, 서로 다른 설치 관리자와 해당 잠금 파일 간의 개별적인 우려 사항, 고유한 요구 사항 및 비호환성을 해결할 필요 없이 이 문제를 해결할 수 있습니다.

이 사양을 구현하는 설치 관리자는 일관된 방식으로 호출할 수 있으므로, 사용자는 설치 관리자를 직접 호출하는 것처럼 원하는 설치 관리자를 사용할 수 있습니다.

용어

설치 관리자 인터페이스: 설치 관리자 백엔드와 범용 설치 관리자가 상호 작용하는 인터페이스입니다.
범용 설치 관리자: 설치 관리자 인터페이스의 선택적 호출 메서드를 호출하여 설치 관리자 백엔드를 호출할 수 있는 설치 관리자입니다. 이는 PEP 517의 build 프로젝트와 같은 설치 관리자 프런트엔드로도 생각할 수 있습니다.
설치 관리자 백엔드: 설치 관리자 인터페이스를 구현하여 범용 설치 관리자가 호출할 수 있도록 하는 설치 관리자입니다. 설치 관리자 백엔드는 범용 설치 관리자이기도 할 수 있지만, 반드시 그래야 하는 것은 아닙니다. 관련 PEP 517에 비유하면 이는 Flit에 해당합니다. 설치 프로그램 백엔드는 기반 설치 프로그램을 감싸는 래퍼 패키지일 수도 있습니다. 예를 들어 Poetry가 이 API를 지원하지 않기로 선택하더라도, 패키지가 래퍼 역할을 하여 적절히 Poetry를 호출하고 Poetry로 설치를 수행할 수 있습니다.
의존성 그룹: 어떤 목적을 위해 서로 관련되어 있으며 동시에 설치해야 하는 의존성 집합입니다. 예를 들어, “test” 의존성 그룹에는 테스트 스위트를 실행하는 데 필요한 의존성이 포함될 수 있습니다. 의존성 그룹을 지정하는 방식은 설치 관리자 백엔드에 달려 있습니다.

동기

이 사양은 지정된 인터페이스를 구현하는 설치 관리자 백엔드를 누구나 호출하고 상호 작용할 수 있도록 하며, 기존의 도구별 설치 프로세스 위에 보편적으로 지원되는 계층을 제공할 수 있게 합니다.

이는 해당 설치 관리자도 이 사양을 구현하는 한, 단일 범용 설치 관리자를 지원하는 환경에서 지정된 인터페이스를 구현하는 모든 설치 관리자를 사용할 수 있게 합니다.

아래에서는 Python 커뮤니티의 이해관계자와 Python 패키지 설치 관리자와 상호 작용하는 모든 사람에게 적용할 수 있는 다양한 사용 사례를 식별합니다. 개발자나 회사의 경우 이 PEP를 통해 Python 패키지 설치 관리자의 기능과 유연성을 높일 수 있습니다.

공급자

공급자는 Python 패키징 및 그에 따른 Python 패키지 설치 관리자와 상호 작용하는 서비스나 소프트웨어 도구를 제공하는 주체(조직, 개인, 커뮤니티 등)입니다. 두 가지 서로 다른 유형의 공급자를 고려합니다.

플랫폼/인프라 공급자

플랫폼 제공업체(클라우드 환경, 애플리케이션 호스팅 등)와 인프라 서비스 제공업체는 사용자가 Python 종속성을 설치할 수 있도록 패키지 설치 프로그램을 지원해야 합니다. 대부분은 pip만 지원하지만, 사용자는 다른 Python 설치 프로그램도 요구하고 있습니다. 대부분의 제공업체는 소프트웨어나 서비스에 추가되는 복잡성과 이를 지원하는 데 필요한 리소스 때문에 둘 이상의 설치 프로그램에 대한 지원을 유지하려 하지 않습니다.

이 사양을 통해 제공업체가 지원하는 유니버설 설치 프로그램이 제공업체 플랫폼에서 해당 설치 프로그램 백엔드에 대한 구체적인 지식을 갖추지 않고도 사용자가 원하는 백엔드를 호출할 수 있도록 합니다. 즉, Poetry가 이 PEP에서 제안하는 설치 프로그램 백엔드 API를 구현하거나(또는 다른 패키지가 Poetry를 래핑하여 해당 API를 제공한다면), 플랫폼 제공업체는 암묵적으로 Poetry를 지원하게 됩니다.

IDE 제공업체

통합 개발 환경은 Python 패키지 설치 및 관리와 상호 작용할 수 있습니다. 대부분은 Python 패키지 설치 프로그램으로 pip만 지원하므로, 사용자는 다른 패키지 설치 프로그램을 사용하여 종속성을 설치하기 위한 우회 방법을 찾아야 합니다. PaaS 및 IaaS 제공업체의 상황과 마찬가지로, IDE 제공업체는 N개의 서로 다른 Python 설치 프로그램에 대한 지원을 유지하려 하지 않습니다. 대신 IDE가 유니버설 설치 프로그램으로 동작하면 설치 프로그램 인터페이스의 구현체(설치 프로그램 백엔드)를 IDE에서 호출할 수 있습니다.

개발자

개발자는 Python 패키지 설치 프로그램과 Python 패키지를 코딩하고 사용하는 팀, 개인 또는 커뮤니티입니다. 개발자는 다음 세 가지 유형으로 구분합니다:

PaaS 및 IaaS 제공업체를 사용하는 개발자

대부분의 PaaS 및 IaaS 제공업체는 하나의 Python 패키지 설치 프로그램인 pip_만 지원합니다. (일부 예외로는 pip와 Pipenv_를 지원하는 Heroku의 Python buildpack_이 있습니다.) 이로 인해 개발자가 이러한 제공업체와 작업할 때 사용할 수 있는 설치 프로그램이 제한되며, 이는 애플리케이션이나 작업 흐름에 최적이 아닐 수 있습니다.

이 PEP를 채택하여 설치 프로그램 백엔드가 되는 설치 프로그램을 사용하면, 제공업체가 유니버설 설치 프로그램을 사용하는 한 사용자는 어떤 Python 패키지 설치 프로그램을 사용해야 하는지 걱정하지 않고 타사 플랫폼/인프라를 이용할 수 있습니다.

IDE를 사용하는 개발자

대부분의 IDE는 pip 또는 소수의 Python 패키지 설치 프로그램만 지원합니다. 따라서 개발자는 지원되지 않는 패키지 설치 프로그램을 사용하는 경우 종속성을 설치하기 위해 우회 방법이나 임시방편적인 방법을 사용해야 합니다.

IDE가 유니버설 설치 프로그램을 사용하거나 제공하면 개발자가 종속성 설치에 사용하고자 하는 모든 설치 프로그램 백엔드를 이용할 수 있으므로, IDE의 작업 흐름에 더 긴밀하게 통합하기 위해 종속성을 설치하는 추가 작업이 필요하지 않습니다.

다른 개발자와 함께 작업하는 개발자

개발자는 다른 개발자와 작업할 때 자신이 선택한 설치 프로그램을 사용할 수 있기를 원하지만, 현재는 종속성 설치의 호환성을 위해 설치 프로그램 선택을 서로 맞춰야 합니다. 선호하는 모든 설치 프로그램이 대신 지정된 인터페이스를 구현한다면 설치 프로그램을 서로 교차하여 사용할 수 있으므로, 개발자는 협업자의 선호와 관계없이 설치 프로그램을 선택할 수 있습니다.

업그레이드 도구 및 패키지 인프라 제공업체

Dependabot, PyUP 등 CI/CD의 패키지 업그레이드 도구와 패키지 인프라는 현재 일부 설치 프로그램을 지원합니다. 이러한 도구는 업그레이드, 다운그레이드 또는 새 해시와 같은 관련 패키지 정보를 사용하여 설치 프로그램별 종속성 파일(예: requirements.txt 또는 poetry.lock)을 직접 구문 분석하고 편집하는 방식으로 작동합니다. 플랫폼 및 IDE 제공업체와 마찬가지로, 대부분의 이러한 제공업체는 N개의 서로 다른 Python 패키지 설치 프로그램을 지원하려 하지 않습니다. 그렇게 하려면 N개의 서로 다른 파일 형식을 지원해야 하기 때문입니다.

현재 이러한 서비스/봇은 각 패키지 설치 프로그램을 개별적으로 지원하도록 구현해야 합니다. 필연적으로 가장 인기 있는 설치 프로그램이 먼저 지원되고, 인기가 낮은 도구는 지원되지 않는 경우가 많습니다. 이 사양을 구현하면 이러한 서비스/봇이 모든 (규정을 준수하는) 설치 프로그램을 지원할 수 있으므로 사용자가 원하는 도구를 선택할 수 있습니다. 이를 통해 이 분야에서 더 많은 혁신이 가능해집니다. 플랫폼과 IDE가 더 이상 “승자”를 성급하게 선택하도록 강요받지 않기 때문입니다.

오픈 소스 커뮤니티

설치 프로그램 요구 사항을 명시하고 이 PEP를 채택하면 Python 패키지 설치 프로그램과 사람들의 작업 흐름 사이의 마찰이 줄어듭니다. 결과적으로 Python 패키지 설치 프로그램과 PaaS나 IDE 같은 타사 인프라/기술 사이의 마찰도 줄어듭니다. 전반적으로 Python 패키지 설치가 더 간단하고 상호 운용 가능해짐에 따라 Python 프로젝트를 더 쉽게 개발하고 배포하며 유지 관리할 수 있게 됩니다.

요구 사항을 명시하고 설치 프로그램을 위한 인터페이스를 만들면 설치 프로그램과 관련된 혁신의 속도도 높일 수 있습니다. 이를 통해 설치 프로그램은 생태계의 나머지 부분도 동일하게 변경하도록 요구하지 않고 실험하고 고유한 기능을 추가할 수 있습니다. 새로운 설치 프로그램이 추가하는 기능이나 종속성을 기록하는 형식과 관계없이 지원하기가 더 쉬워지고 지원될 가능성도 커지는 한편, 이를 수행하는 데 필요한 개발자의 시간과 리소스도 줄어듭니다.

사양

관련 PEP 517이 빌드 시스템을 명세하는 방식과 유사하게, 설치 시스템 정보는 pyproject.toml 파일의 install-system 테이블 아래에 위치합니다.

[install-system]

install-system 테이블은 설치 시스템과 관련된 데이터 및 정보를 저장하는 데 사용됩니다. 이 테이블에는 필수 키가 여러 개 있으며, requires와 install-backend가 해당합니다. requires키에는 installer backend를 실행하는 데 필요한 최소 요구 사항이 저장되며, 이 요구 사항은 universal installer가 설치합니다. install-backend 키에는 설치 백엔드 진입점의 이름이 저장됩니다. 이를 통해 universal installer는 installer backend자체를 실행하는 데 필요한 요구 사항(installer backend자체가 설치할 요구 사항은 아님)을 설치하고 installer backend를 호출할 수 있습니다.

필수 키 중 하나라도 누락되었거나 비어 있으면 universal installer는 오류를 발생시켜야 합니다.

이 인터페이스와 상호 작용하는 모든 패키지 이름은 PEP 508의 “Dependency specification for Python Software Packages” 형식을 따라야 한다고 간주됩니다.

install-system 테이블 예시:

#pyproject.toml
[install-system]
#Eg : pipenv
requires = ["pipenv"]
install-backend = "pipenv.api:main"

설치 프로그램 요구 사항:

requires키로 지정되는 요구 사항은 PEP 517에서 지정한 제약 조건을 충족해야 합니다. 구체적으로 종속성 순환은 허용되지 않으며, 순환이 감지되면 universal installer는 종속성 설치를 거부해야 합니다.

추가 매개변수 또는 도구별 데이터

추가 매개변수나 도구(installer backend) 데이터도 pyproject.toml 파일에 저장할 수 있습니다. 이는 PEP 518에서 지정한 “tool.*” 테이블에 저장합니다. 예를 들어 installer backend가 Poetry이고 여러 종속성 그룹을 지정하려는 경우 tool.poetry 테이블은 다음과 같이 표시될 수 있습니다.

[tool.poetry.dev-dependencies]
dependencies = "dev"

[tool.poetry.deploy]
dependencies = "deploy"

설치 백엔드가 적절하다고 판단하는 다른 방식(예: 별도의 구성 파일)으로 데이터를 저장할 수도 있습니다.

설치 프로그램 인터페이스:

installer interface는 필수 훅과 선택적 훅을 포함합니다. 규정을 준수하는 installer backends는 필수 훅을 반드시 구현해야 하며 선택적 훅은 구현할 수 있습니다. universal installer는 installer backend와 universal installer의 역할을 모두 수행하기 위해 installer backend의 훅을 직접 구현할 수 있지만, 반드시 구현해야 하는 것은 아닙니다.

모든 훅은 하위 호환성을 위해, installer backend가 필요로 할 수 있지만 이미 지정되지 않은 임의의 매개변수인 **kwargs를 받습니다. 예상하지 못한 매개변수가 installer backend에 전달되면 이를 무시해야 합니다.

다음 정보는 PEP 517의 해당 섹션과 유사합니다. 훅은 키워드 인자로 호출될 수 있으므로, 이를 구현하는 설치 백엔드는 인자의 순서와 위에서 언급한 인자 이름이 시그니처에 모두 일치하는지 주의해야 합니다.

모든 훅은 stdout 및 stderr에 임의의 정보 텍스트를 출력할 수 있습니다. 훅은 stdin에서 읽어서는 안 되며, 범용 설치 관리자는 훅을 호출하기 전에 stdin을 닫을 수 있습니다.

범용 설치 관리자는 백엔드의 stdout 및/또는 stderr를 캡처할 수 있습니다. 백엔드가 출력 스트림이 터미널/콘솔이 아님을 감지하면(예: sys.stdout.isatty()가 아님), 해당 스트림에 기록하는 모든 출력이 UTF-8로 인코딩되도록 해야 합니다. 캡처된 출력이 유효한 UTF-8이 아니더라도 범용 설치 프로그램은 절대로 실패해서는 안 됩니다. 그러나 그러한 경우 모든 정보를 보존하지 못할 수 있습니다(예를 들어 Python에서 replace 오류 처리기를 사용하여 디코드할 수 있습니다). 출력 스트림이 터미널인 경우, 터미널에서 실행되는 모든 프로그램과 마찬가지로 설치 백엔드는 출력을 정확하게 표시할 책임이 있습니다.

훅이 예외를 발생시키거나 프로세스를 종료시키면 오류를 나타냅니다.

필수 훅:

invoke_install

의존성을 설치합니다.:

def invoke_install(
    path: Union[str, bytes, PathLike[str]],
    *,
    dependency_group: str = None,
    **kwargs
) -> int:
    ...

path : 설치 백엔드가 호출되어야 하는 절대 경로입니다(예: pyproject.toml이 위치한 디렉터리).
dependency_group : 설치 백엔드가 설치해야 하는 의존성 그룹을 지정하는 선택적 플래그입니다. 의존성 그룹이 존재하지 않으면 설치 시 오류가 발생합니다. 설치 백엔드가 의존성 그룹을 지원하는 경우, 사용자는 get_dependency_groups()를 호출하여 모든 의존성 그룹을 찾을 수 있습니다.
**kwargs : 설치 백엔드에 필요할 수 있지만 아직 지정되지 않은 임의의 매개변수로, 하위 호환성을 허용합니다.
반환값 : 종료 코드(int)입니다. 성공하면 0이고, 실패하면 양의 정수입니다.

범용 설치 관리자는 설치 성공 여부를 판단하는 데 종료 코드를 사용하며, 종료 코드 자체를 반환하는 것이 좋습니다.

선택적 훅:

invoke_uninstall

지정된 의존성을 제거합니다.:

def invoke_uninstall(
    path: Union[str, bytes, PathLike[str]],
    *,
    dependency_group: str = None,
    **kwargs
) -> int:
    ...

path : 설치 백엔드가 호출되어야 하는 절대 경로입니다(예: pyproject.toml이 위치한 디렉터리).
dependency_group : 설치 백엔드가 제거해야 하는 의존성 그룹을 지정하는 선택적 플래그입니다.
**kwargs : 설치 백엔드에 필요할 수 있지만 아직 지정되지 않은 임의의 매개변수로, 하위 호환성을 허용합니다.
반환값 : 종료 코드(int)입니다. 성공하면 0이고, 실패하면 양의 정수입니다.

범용 설치 프로그램은 설치 백엔드를 범용 설치 프로그램자체가 호출된 동일한 경로에서 호출해야 합니다.

범용 설치 관리자는 제거 성공 여부를 판단하는 데 종료 코드를 사용하며, 종료 코드 자체를 반환하는 것이 좋습니다.

get_dependencies_to_install

invoke_install(...)로 설치될 의존성을 반환합니다. 이를 통해 패키지 업그레이더(예: Dependabot)는 의존성 파일을 구문 분석하지 않고도 설치를 시도하는 의존성을 검색할 수 있습니다.:

def get_dependencies_to_install(
    path: Union[str, bytes, PathLike[str]],
    *,
    dependency_group: str = None,
    **kwargs
) -> Sequence[str]:
    ...

path : 설치 백엔드가 호출되어야 하는 절대 경로입니다(예: pyproject.toml이 위치한 디렉터리).
dependency_group : 해당 의존성 그룹에 대해 invoke_install(...)이 설치할 의존성 그룹을 지정합니다.
**kwargs : installer backend이 요구할 수 있지만 아직 지정되지 않은 임의의 매개변수로, 하위 호환성을 지원합니다.
반환값: 설치할 의존성(PEP 508 문자열) 목록입니다.

그룹이 지정된 경우, installer backend는 제공된 의존성 그룹에 해당하는 의존성을 반드시 반환해야 합니다. 지정된 그룹이 존재하지 않거나 installer backend가 의존성 그룹을 지원하지 않는 경우, installer backend는 반드시 오류를 발생시켜야 합니다.

그룹이 지정되지 않았고 installer backend가 기본/미지정 그룹이라는 개념을 제공하는 경우, installer backend는 기본/미지정 그룹에 대한 의존성을 반환할 수 있지만, 그렇지 않으면 반드시 오류를 발생시켜야 합니다.

get_dependency_groups

설치 가능한 의존성 그룹을 반환합니다. 이를 통해 universal installers는 installer backend가 알고 있는 모든 의존성 그룹을 열거할 수 있습니다.:

def get_dependency_groups(
    path: Union[str, bytes, PathLike[str]],
    **kwargs
) -> AbstractSet[str]:
    ...

path : installer backend를 호출해야 하는 절대 경로입니다(예: pyproject.toml이 위치한 디렉터리).
**kwargs : installer backend이 요구할 수 있지만 아직 지정되지 않은 임의의 매개변수로, 하위 호환성을 지원합니다.
반환값: 알려진 의존성 그룹의 집합으로, 문자열로 표현됩니다. 빈 집합은 의존성 그룹이 없음을 나타냅니다.

update_dependencies

입력된 패키지 목록을 기반으로 의존성 파일을 출력합니다.:

def update_dependencies(
    path: Union[str, bytes, PathLike[str]],
    dependency_specifiers: Iterable[str],
    *,
    dependency_group=None,
    **kwargs
) -> int:
    ...

path : installer backend를 호출해야 하는 절대 경로입니다(예: pyproject.toml이 위치한 디렉터리).
dependency_specifiers : 업데이트할 의존성을 나타내는 PEP 508 문자열의 이터러블입니다. 예: ["requests==2.8.1", ...]입니다. 특정 의존성 그룹에 대해 선택적으로 지정할 수 있습니다.
dependency_group : 패키지 목록이 속하는 의존성 그룹입니다.
**kwargs : installer backend이 요구할 수 있지만 아직 지정되지 않은 임의의 매개변수로, 하위 호환성을 지원합니다.
반환값: 종료 코드(int)입니다. 성공하면 0이고, 실패하면 양의 정수입니다.

예

pip와 해당 requirements 파일을 사용하여 종속성 그룹을 처리하는 설치 백엔드를 구현하는 방안을 고려해 봅시다. 구현은 (매우 대략적으로) 다음과 같을 수 있습니다.:

import subprocess
import sys


def invoke_install(path, *, dependency_group=None, **kwargs):
    try:
        return subprocess.run(
            [
                sys.executable,
                "-m",
                "pip",
                "install",
                "-r",
                dependency_group or "requirements.txt",
            ],
            cwd=path,
        ).returncode
    except subprocess.CalledProcessError as e:
        return e.returncode

이 패키지의 이름을 pep650pip라고 지정하면, pyproject.toml에 다음과 같이 지정할 수 있습니다.:

[install-system]
  #Eg : pipenv
  requires = ["pep650pip", "pip"]
  install-backend = "pep650pip:main"

근거

모든 훅은 하위 호환성을 지원하고, 훅에 필요하지 않지만 사용자가 추가 정보를 제공해야 하는 도구별 installer backend기능을 허용하기 위해 **kwargs를 받습니다.

installer backends는 Python 패키지여야 하지만, 호출되었을 때 수행하는 작업은 해당 도구의 구현 세부 사항입니다. 예를 들어, installer backend는 플랫폼 패키지 관리자의 래퍼로 작동할 수 있습니다(예: apt).

인터페이스는 설치 백엔드가 어떻게 작동해야 하는지를 어떤 방식으로든 명세하려고 하지 않습니다. 이는 installer backends가 각자의 방식으로 혁신하고 문제를 해결할 수 있도록 하기 위한 의도적인 선택입니다. 또한 이는 OS 패키징이 installer backend의 영역이므로 이 PEP가 OS 패키징에 대해 어떠한 입장도 취하지 않는다는 것을 의미합니다.

파이썬으로 API를 정의한다는 것은 결국 일부 파이썬 코드를 실행해야 한다는 의미입니다. 그렇다고 해서 비파이썬 설치 백엔드를 사용할 수 없는 것은 아닙니다(예: mamba). 이러한 백엔드는 파이썬 코드에서 하위 프로세스로 실행할 수 있기 때문입니다.

하위 호환성

이 PEP는 범용 설치 프로그램에 새로운 기능만 추가하므로 기존 코드와 기능에 영향을 주지 않습니다. 기존 설치 프로그램은 기존 기능과 사용 사례를 유지해야 하므로 하위 호환성 문제가 발생하지 않습니다. 이 새로운 기능을 활용하려는 코드만 기존 코드에 변경을 가할 동기를 갖게 됩니다.

보안 영향

설치 프로그램 사양을 표준화하더라도 악의적인 사용자가 어떤 대상에 대해 더 큰 권한이나 더 쉬운 접근 권한을 갖게 되지는 않습니다. 이 PEP에서 지정한 인터페이스를 통해 범용 설치 프로그램이 호출할 수 있는 설치 프로그램은 사용자가 명시적으로 선언합니다. 사용자가 악의적인 설치 프로그램을 선택했다면, 범용 설치 프로그램으로 이를 호출하는 것은 사용자가 설치 프로그램을 직접 호출하는 것과 다르지 않습니다. 악의적인 설치 프로그램이 설치 백엔드라고 해서 추가 권한이나 능력을 갖게 되는 것은 아닙니다.

거부된 아이디어

표준화된 잠금 파일

표준화된 잠금 파일은 설치 프로그램 요구 사항을 지정하는 방식이 해결하는 여러 동일한 문제를 해결할 수 있습니다. 예를 들어 PaaS/IaaS가 이를 생성한 설치 프로그램과 관계없이 표준화된 잠금 파일을 읽을 수 있는 하나의 설치 프로그램만 지원하도록 할 수 있습니다. 표준화된 잠금 파일의 문제는 파이썬 패키지 설치 프로그램마다 필요한 사항이 다르다는 점과 잠금 파일을 통해 재현 가능한 환경을 만드는 데 근본적인 문제가 있다는 점입니다(이는 주요 이점 중 하나입니다).

설치 프로그램 간 종속성 파일에 저장되는 요구 사항과 정보는 크게 다르며 설치 프로그램의 기능에 따라 달라집니다. 예를 들어 Poetry와 같은 파이썬 패키지 설치 프로그램은 모든 파이썬 버전과 플랫폼에 대한 정보를 필요로 하며 적절한 해시를 계산하지만, pip은 그렇지 않습니다. 또한 pip은 동일한 환경을 재현하는 것(정확히 동일한 종속성을 설치하는 것)을 보장할 수 없습니다. 이는 해당 기능의 범위를 벗어나기 때문입니다. 따라서 표준화된 잠금 파일은 구현하기가 더 어려우며 잠금 파일을 도구별로 만드는 것이 더 적절해 보입니다.

Python 개선 제안 한국어 번역