PEP 773 – Windows용 Python 설치 관리자
- Author:
- Steve Dower
- Discussions-To:
- Discourse thread
- Status:
- Final
- Type:
- Standards Track
- Topic:
- Release
- Created:
- 21-Jan-2025
- Post-History:
- 18-Dec-2024, 21-Jan-2025
- Replaces:
- 397, 486
- Resolution:
- 25-Apr-2025
번역·라이선스 안내
이 비공식 한국어 번역은 원문 Copyright 절의 Public Domain or CC0-1.0, whichever is more permissive 조건에 따라 제공합니다. 원저자와 공식 원문은 그대로 표시합니다. 수정되지 않은 기준 원문 · 공식 최신판
초록
Windows에서 python.org Python 배포판을 설치하는 과정은 복잡합니다. 사용자 경험 수준이 대체로 비슷한 세 가지 주요 방식이 있지만, 이들 모두 현대적인 사용 시나리오를 충족하지 못한다는 점을 비롯해 저마다 다른 한계를 안고 있습니다. 이 PEP는 해당 플랫폼의 기존 설치 프로그램이 충족하던 요구를 모두 충족하면서도 그 한계는 대부분 피하고, 코어 팀이 앞으로 여러 해 동안 릴리스를 관리할 수 있게 하는 단일 Windows 설치 워크플로 도구의 설계를 제안합니다.
새 설치 프로그램에서 Windows의 기본 Python을 실행하는 권장 명령은 python이 되며, 여러 버전을 관리하는 명령(특정 버전 실행 포함)은 py가 됩니다. 사용자는 PATH 환경 변수에 항목을 하나 더 추가하여 전역 python3.x 명령을 사용하도록 선택할 수도 있습니다. 기능을 가장 간결하게 개괄한 고수준 설명은 “How to teach this” 섹션에 있으므로, 그 섹션부터 읽기를 권장합니다.
기존 .exe 설치 프로그램과 py 런처는 폐기 예정으로 지정되며, 이 PEP가 승인되고 2년이 지난 뒤부터는 더 이상 릴리스되지 않습니다. 기존 임베드 가능 배포판은 더 이상 다운로드 목록에 올라가지 않지만, 설치 관리자를 통해서는 계속 받을 수 있습니다. Windows 스토어 앱은 즉시 설치 관리자로 대체됩니다.
읽는 분께
이 문서는 Windows용 Python의 기존 설치 형식을 새 형식으로 대체하는 안을 “승인”할지 “거부”할지 결정하는 데 도움을 주기 위해 작성한 상세한 제안입니다. 이 문서는 구속력 있는 명세가 아니며, 사용자 문서나 상호 운용성 명세도 아닙니다. 실제 구현은 요구 사항이 바뀌면서 시간이 지남에 따라 달라질 수 있으며, 이를 이 PEP의 “위반”으로 보지 않습니다. 공개적으로 사용하도록 의도된 모든 인터페이스와 프로토콜은 별도로 문서화되며, 표준 폐지 일정에 따라 유지 관리됩니다.
Windows에 Python을 설치하는 방법에 대한 문서는 docs.python.org/using/windows.html에서 볼 수 있습니다.
배경
사용자가 Python 런타임을 설치하려는 이유가 되는 요구는 매우 다양합니다. 많은 사용자, 아마도 대부분의 사용자는 간단한 작업을 하거나 다른 사람에게 개념을 가르치는 데 쓰는 짧은 스크립트를 실행하는 일(어쩌면 직접 작성하는 일)에 관심이 있습니다. 기존 코드나 다른 애플리케이션과 통합하기 위해 특정 버전을 찾는 사용자도 있습니다. 테스트를 위해 여러 인터프리터 버전을 모두 갖추려는 사용자도 있습니다.
이 섹션에서는 사용자가 “Python 설치”에 대해 갖는 기대를 논의하고, Windows용 기존 설치 프로그램을 개괄한 뒤, 이 설치 프로그램들에 내재한 빈틈과 과제를 짚어 봅니다.
기대 사항
폭넓은 경험적 사례와 (반드시 공개된 것은 아니지만) 활용 가능한 정량적 데이터 분석을 바탕으로, Windows를 쓰는 대다수 Python 사용자에 대해 다음과 같이 주장합니다:
- 대부분의 사용자는 최신 안정 버전만을 원합니다
- 대부분의 사용자는 “원 클릭”(또는 그보다 적은 조작)으로 끝나는 설치를 원합니다
- 대부분의 사용자는 관리자 권한을 사용하고 싶어 하지 않습니다
- 대부분의 사용자는 유지 보수 업데이트를 설치하면 이점을 얻습니다
- 대부분의 사용자는 설치 후
python명령이 동작하리라고 기대합니다
이러한 주장의 주된 근거는 사용자가 직접 가장 많이 고르는 설치 프로그램이 python.org의 최신 안정 릴리스와 Windows 스토어의 최신 안정 릴리스이며, 두 설치 프로그램 모두 이 요구 사항을 충족한다는 점입니다.
그 밖의 주요 사용자 집단에 대해서는 다음과 같이 가정합니다. 이러한 집단은 서로 일부 겹칠 수 있으며, 적어도 일부 사용자는 이 모든 것을 기대합니다.
- 일부 사용자는 Python을 프로그래밍 방식으로 설치하기를 원합니다
- 일부 사용자는 특정 버전을 설치하기를 원합니다
- 일부 사용자는 여러 버전을 설치하기를 원합니다
- 일부 사용자는 자신의 컴퓨터를 사용하는 모든 사용자를 위해 설치하기를 원합니다
- 일부 사용자는 시작 메뉴 바로 가기를 원하지 않습니다
- 일부 사용자는 프로젝트 빌드 과정의 일부로 설치하기를 원합니다
- 일부 사용자는 프로젝트 설치 과정의 일부로 설치하기를 원합니다
- 일부 사용자는 설치한 Python을 전혀 업데이트하지 않으려고 합니다
- 일부 사용자는 설치 후
py명령이 동작하기를 기대합니다
이러한 가정은 모두 시간이 지나면서 실제로 존재함이 입증되었지만, 상대적인 중요도는 정량화되지 않았습니다. NuGet 패키지와 임베드 가능한 배포판은 이러한 요구 대부분을 충족할 수 있습니다.
전통적인 설치 프로그램
전통적인 설치 프로그램은 python.org에서 직접 내려받을 수 있는 실행 파일로, Python 개발 키트 전체를 설치합니다. 여기에는 CPython 인터프리터, 표준 라이브러리, Python 헤더와 임포트 라이브러리, Tcl 및 Tk 빌드, HTML 파일 형태의 문서, 런타임 및 표준 라이브러리 테스트 스위트, Python과 IDLE의 시작 메뉴 바로 가기, 디버깅 심볼과 바이너리의 디버그 빌드, py.exe 런처와 그 파일 연결이 포함되며, 사용자의 PATH 환경 변수를 수정하고, 시스템에서 긴 경로 지원을 활성화하고, 표준 라이브러리의 .pyc 파일을 미리 생성하고, pip을 설치하는 기능도 포함됩니다. 3.13부터는 실험적인 자유 스레드(free-threaded) 바이너리 세트도 포함됩니다. 이러한 구성 요소 중 상당수는 선택 사항입니다.
실행 파일을 내려받은 후 사용자에게는 “빠른 설치” 옵션이 제시되며, 이 옵션은 대부분의 옵션을 활성화한 상태로 사용자 디렉터리에 설치합니다. 저희는 대부분의 사용자가 이 옵션을 선택한다고 생각합니다.
빠른 설치와 나란히 제공되는 두 번째 옵션을 선택하면 두 페이지 분량의 옵션 화면으로 이동하며, 여기에는 설치하지 않아도 되는 구성 요소 목록과 함께 설치 디렉터리, 모든 사용자를 위한 설치 여부 등의 다른 옵션이 표시됩니다.
이러한 옵션은 모두 명령줄에서 지정할 수 있으며, UI를 전혀 표시하지 않고 설치를 진행하는 옵션도 있습니다. 피드백과 버그 보고에 따르면, 이러한 옵션은 모두 적어도 일부 사용자가 사용하고 있습니다. 그러나 저희는 설치 원격 측정(telemetry) 데이터를 수집하지 않으므로, 어떤 옵션이 다른 옵션보다 더 중요한지 알 방법이 없습니다.
내부적으로 전통적인 설치 프로그램은 Wix Toolset 설치 프로그램 프레임워크로 생성된 Burn 번들이며, 기능별로 하나 이상의 MSI 파일을 포함합니다. 이 프레임워크는 Microsoft 자체에서도 광범위하게 사용하며, Windows 설치 프로그램(Windows Installer)을 사용하는 가장 직접적인 방법을 제공합니다. 번들은 제공되는 템플릿을 기반으로 만든 맞춤형 C++ 애플리케이션으로, 이를 통해 설치 프로그램의 전반적인 동작을 조정하여 실제로 어떤 MSI 파일을 설치할지 정확하게 결정할 수 있습니다. 파일 복사, 레지스트리 갱신, 바로 가기 생성 과정은 전적으로 Windows 설치 프로그램(Windows Installer)이 처리합니다.
의도된 용도 외에도, 많은 사용자가 등록되지 않은 설치나 자동화된 CI 시스템 설치 같은 다른 시나리오에 전통적인 설치 프로그램을 사용할 (또는 사용하려고 시도할) 것으로 알고 있습니다. 더 나은 대안이 있기는 하지만 그만큼 눈에 잘 띄지 않으며, 향후 설계에서는 이러한 시나리오가 더 쉬워지기를 기대합니다.
Windows 스토어
CPython용 Windows Store 패키지는 일반 릴리스 프로세스의 일부로 만들어지며, 다른 패키지와 거의 모두 동일한 바이너리를 사용합니다. 앱 스토어 패키지에 포함되기 때문에 기본 python.exe는 자신의 위치를 올바르게 파악할 수 있도록 개선되었으며, PATH 환경 변수 설정이 없는 점을 보완하기 위해 대체 pip.exe 및 기타 바로 가기가 포함되어 있습니다. 이는 저장소의 PC\python_uwp.cpp에 구현되어 있습니다.
이 패키지는 Microsoft Store 앱에서 Python을 검색하여 설치하며, 검색하면 3.8 이후의 각 메이저 버전에 대한 결과가 표시됩니다. 그런 다음 사용자가 버전을 선택하여 설치해야 합니다. 이 패키지에는 CPython 인터프리터, 표준 라이브러리, Tcl/Tk, IDLE, pip이 포함되어 있으며, 파일 연결, 시작 메뉴 바로 가기, 그리고 python.exe, python3.exe, python3.X.exe, pip[3[.X]].exe, idle[3[.X]].exe에 대한 전역 명령을 생성합니다. PATH 수정은 가능하지도 않고 필요하지도 않지만, 사용자가 “앱 실행 별칭 관리(Manage App Execution Alias)” 설정 페이지에서 전역 바로 가기를 관리해야 할 수는 있습니다.
또한 Microsoft는 새로 설치한 Windows에 기본 python.exe 명령을 추가했습니다. 이 명령은 아직 Python이 설치되지 않은 컴퓨터에서 사용자가 Python을 실행하려는 시도를 가로챕니다. 이 명령을 직접 실행하면 Microsoft Store 앱이 열리면서 권장 Python 앱(일반적으로 최신 버전)이 있는 페이지를 보여 줍니다. 이 앱은 전적으로 Microsoft가 관리합니다. Python 앱(이 앱은 업스트림 Python 프로젝트가 실제로 관리합니다)과 관련된 원격 측정 데이터에 따르면, 매달 약 300,000건의 설치가 이 리디렉터를 통해 이루어지며, 이는 해당 버전 전체 설치의 약 90%를 차지합니다.
내부적으로 Store 패키지는 APPX 또는 MSIX로 알려진 Microsoft의 새로운 앱 설치 프로그램 기술을 기반으로 합니다. 이는 본질적으로 소량의 메타데이터가 포함된 일반 ZIP 파일이지만, 설치를 운영 체제가 처리한다는 점이 다릅니다. 이 파일은 항상 고정된 위치에 압축이 풀리며, 이 위치는 모든 사용자가 접근할 수 있지만 누구도 수정할 수 없고, 파일은 최신 릴리스로 자동 업데이트됩니다. 사용자 자신의 데이터는 사용자 프로필 내의 OS가 관리하는 위치에 저장되며, 일반적인 OS 기능을 사용하여 초기화, 백업, 복원할 수 있습니다.
NuGet 패키지
CPython용 NuGet 패키지는 일반 릴리스 프로세스의 일부로 만들어지고 게시됩니다. 내용물은 기존 설치 프로그램과 동일합니다. NuGet 패키지는 nuget.org에 게시됩니다. nuget.org는 일반적으로 .NET 언어와 연관된 패키지 관리자이지만, Visual Studio가 지원하는 모든 프로젝트와 긴밀하게 통합되어 있습니다. 따라서 일반 빌드 프로세스의 일부로 Python을 가볍게 설치하려는 사용자에게 적합한 형식이며, 임베딩 시나리오를 단순화할 수 있습니다.
이 패키지는 NuGet API를 사용할 수 있는 모든 도구로 설치할 수 있으며, 패키지의 URL을 알고 있다면 직접 다운로드할 수도 있습니다. 이 패키지는 약간의 메타데이터가 포함된 일반 ZIP 파일입니다. 여기에는 CPython 인터프리터, 표준 라이브러리, 개발용 헤더 및 임포트 라이브러리, pip이 포함되어 있습니다. 설치 시에는 어떤 코드도 실행하지 않으며, 사용자가 그 안에 포함된 python.exe를 실행하려면 패키지의 위치를 직접 찾아야 합니다.
임베드 가능 패키지
CPython용 임베드 가능 패키지는 일반 릴리스 프로세스의 일부로 만들어지고 게시됩니다. 이 패키지는 기존 설치 프로그램과 함께 python.org에 게시됩니다. 내용은 동일하지만, 모든 바이너리를 최상위 수준에 저장하고 표준 라이브러리를 ZIP 파일로 묶도록 레이아웃이 변경되었습니다. 배포판에 포함된 파일만 사용하고 환경 변수나 레지스트리 항목은 무시하도록 sys.path를 재정의하는 ._pth 파일이 포함되어 있습니다.
이 패키지는 더 큰 애플리케이션에 임베드하는 것을 목적으로 하므로 pip을 포함하지 않습니다. 배포 후에는 런타임이 자신이 속한 앱의 내부 구현 세부 사항이 되어야 하므로, 다른 라이브러리는 빌드 시점에 설치해야 합니다.
본래의 용도 외에도, 일부 사용자는 이 패키지를 런타임 패키지가 아닌 개발 키트로 사용하려고 합니다. 이는 해당 사용자들이 “무거운” 설치 프로그램을 피하고 싶어 하고, 이 패키지가 “포터블” 설치(압축을 풀고 실행)를 위한 것이라고 믿기 때문인 것으로 보입니다. 아마도 이 패키지가 python.org 다운로드 페이지에 나열된 유일한 ZIP 파일 선택지이기 때문일 것입니다(이는 해당 페이지에서 명확성을 확보하고 선택지를 제한하는 것이 얼마나 중요한지를 보여 줍니다). 향후의 설치 프로그램 설계가 이러한 혼란을 피하거나 줄이기를 기대합니다.
대체 배포판
코어 팀의 소관 밖이기는 하지만, Windows용 Python 대체 배포판은 런타임 설치에 프로젝트, 워크플로 또는 환경 중심 모델을 사용하는 경우가 많습니다. 이는 도구를 먼저 설치한 다음, 그 도구를 사용해 런타임과 기타 의존성을 포함하는 작업 공간을 만든다는 뜻입니다. 이러한 도구의 예로는 conda와 uv가 있습니다.
이러한 도구에 대해 짚어 볼 만한 점이 두 가지 있습니다. 첫째, 이러한 도구는 대개 런타임을 위한 추가 진입점이나 파일을 설치하지 않아 설치가 빠르고 단일 프로젝트로 격리된다는 점에서, 영향이 적다고 자주 호평받습니다. 둘째, 사용자들은 특정 버전의 런타임을 쉽게 선택할 수 있다는 점, 또는 기존 명세(또는 제약 조건)가 대신 선택해 주므로 아예 선택할 필요가 없다는 점을 높이 평가하는 경우가 많습니다.
이러한 도구는 위에서 설명한 두 번째 기대 사항 중 상당수를 충족하는 경향이 있으며, 대개 여러 작업을 단일 명령으로 결합하여 여러 명령을 사용하고 조합하는 방법을 익히는 데 드는 인지적 부담을 줄입니다.
또한 코어 팀은 이러한 대체 배포판을 어떤 업스트림 배포판의 경쟁자로도 보지 않는다는 점을 짚어 둘 필요가 있습니다. 대체 배포판은 오픈 소스 생태계가 본래 의도된 대로 작동하는 방식의 근본적인 일부입니다. 모든 시나리오가 워크플로 도구나 사전 빌드된 패키지로 잘 지원되는 것은 아니므로, 저희 자체 배포판은 이를 사용하기로 선택한 사람들을 위한 편의 수단입니다.
과제
현재의 설치 프로그램들에는 수많은 과제가 있으며, 이는 크게 두 가지 범주로 나뉩니다. 하나는 어긋나거나 충족할 수 없는 사용자 기대이고, 다른 하나는 전반적인 신뢰성 부족입니다.
기존 설치 프로그램은 신뢰성이 가장 떨어집니다. Windows 설치 프로그램(Windows Installer) 기술은 매우 오래되었으며, 사실상 더 이상 개발되지 않습니다. 기본 기능은 괜찮지만, 바이러스 검사기, 다른 설치 프로그램, 시스템 구성, 관리자 정책, 심지어 설치 프로그램과 같은 디렉터리에 있는 다른 파일 등 여러 곳에서 간섭이 발생할 수 있습니다. 게다가 업데이트 패치, 증분 업데이트, 자동 롤백과 같은 고급 기능이자 유용한 기능 대부분은 Python 사용자에게 중요하지 않습니다.
대부분의 사용자 기대는 기존 설치 프로그램에 의해 정의되었으므로, 정의상 기존 설치 프로그램은 그 기대를 충족합니다. 한 가지 주요한 공백은 “관리되지 않는” 설치, 즉 등록 없이 사용자 시스템에 파일을 복사하기만 하는 것에 해당하는 설치를 만들 수 없다는 점입니다. 한 번 설치한 뒤 다시 설치하려고 하면, 기존 설치를 관리(또는 업그레이드)하는 것밖에 할 수 없습니다. 이로 인해 업데이트 시 설치 위치가 옮겨질 수 있으며, 그러면 사용자 환경이 망가집니다.
또한 PATH 환경 변수를 지능적으로 수정할 수 없습니다. 기껏해야 설치 경로를 앞이나 뒤에 추가할 수 있을 뿐입니다. 이로 인해 대개 가장 최근에 설치한 Python이 가장 높은 우선순위를 갖게 됩니다. 예를 들어 사용자가 Python 3.14를 설치한 상태에서 3.13을 설치(또는 업데이트)하면, python 명령은 나중 버전에서 이전 버전으로 전환됩니다.
PEP 397에서 정의되고 PEP 514에 의해 암묵적으로 갱신된 py.exe 런처는 바로 이 문제를 피하려는 시도입니다. 이 런처는 PATH에 의존하지 않고 설치된 버전을 찾는 자체 로직을 사용합니다. 그러나 PEP 514 로직은 프리릴리스나 실험적 빌드를 특별하게 취급할 수 없으므로, py.exe는 기본적으로 사용자가 기대하는 비실험적 버전보다 이러한 빌드를 선호하는 경우가 많습니다.
Windows Store 패키지는 전역 바로 가기를 예외로 하면 매우 안정적입니다. 이 바로 가기들은 자체 디렉터리를 추가하려고 PATH를 수정하지 않습니다. 대신 모든 앱이 정의한 바로 가기가 모여 있는, OS가 관리하는 단일 디렉터리에 만들어집니다. 사용자는 PATH를 수정하여 이 디렉터리를 제외하거나 우선순위를 낮출 수 있으며, 그러면 동작이 불안정해지거나 일관되지 않게 됩니다. 과거에는 설치 프로그램 때문에 이런 상황이 생기기도 했습니다. 예를 들어 스토어에서 Python을 설치한 뒤 PATH 수정 옵션을 켠 채로 기존 설치 프로그램으로 Python을 설치하면, 거의 항상 나중에 설치한 Python이 스토어 패키지의 Python을 가리게 됩니다.
스토어 패키지가 충족하지 못하는 사용자 기대는 주로 성능과 기술적인 측면에 관한 것입니다. 앱 실행에 따르는 오버헤드 때문에 Python의 시작 속도가 느립니다. 앱은 서로 격리되도록 설계되어 있고 버전마다 자신만의 공간을 가지므로, 서로 다른 버전의 Python이 숨겨진 디렉터리(AppData나 TEMP 등)를 통해 통신하기가 더 어렵습니다. 앱에는 DLL 하이재킹 방지처럼 레거시 애플리케이션에서는 보통 비활성화되어 있는 더 엄격한 보안 요구 사항이 적용되며, 이 때문에 일부 라이브러리가 제대로 동작하지 않습니다. python3와 python 바로 가기는 시스템 설정에서 관리되는데, 그 사용자 인터페이스가 그다지 좋지 않습니다(Microsoft에 따르면 개선될 예정도 없습니다). 이를 관리하지 않으면 원하지 않는 버전이 실행되기 비교적 쉽습니다. 다만 일반적으로 대상은 사용자가 직접 바꿔야만 변경되며, 다른 앱을 설치하는 것만으로는 바뀌지 않습니다.
NuGet 패키지와 임베드 가능 배포판은 둘 다 아카이브 파일의 압축을 푸는 것만큼 간단하고 안정적으로 설치됩니다. 다만 많은 Python 사용자에게는 이것이 익숙한 작업이 아니라는 점을 짚어 둘 필요가 있습니다. 이 두 패키지는 설치 관리 기능을 전혀 제공하지 않으며, 삭제한 뒤 다시 압축을 푸는 방법 외에는 안정적으로 업데이트할 수 없습니다. 충족되지 못하는 사용자 기대는 거의 항상 사용자가 잘못된 설치 프로그램을 선택한 데서 비롯됩니다. 두 패키지는 모두 특수한 경우를 위한 것이고 문서에도 그렇게 명시되어 있습니다. 그런데도 단순한 ZIP 파일이라는 점에 끌려 일부 사용자가 잘못 선택하고 문제를 겪습니다.
PyManager 개요
PyManager는 우리가 제안하는 대체 설치 프로그램 도구의 내부 이름입니다. 이 도구는 Windows 스토어와 python.org 양쪽에서 MSIX 패키지로 배포됩니다. 어느 쪽에서 내려받든 동일한 패키지를 받게 되며, 두 경우 모두 새 릴리스에 대해 (스토어를 통한) 자동 업데이트를 지원합니다.
사용자에게 보이는 이름은 “Python Install Manager”이며, Python Software Foundation이 게시합니다. 게시한 후에는 Microsoft에 python.exe 스텁이 이 새 앱을 열도록 수정해 달라고 요청할 것입니다.
이 앱은 Python 버전을 직접 제공하지 않습니다. 대신 사용자가 당연히 동작하리라 기대하는 전역 명령과 파일 연결, 시작 메뉴 바로 가기를 제공합니다. 설치가 끝나면 OS가 사용자에게 앱을 실행하라고 안내하며, 앱을 실행하면 현재 릴리스의 CPython이 자동으로 설치된 뒤 실행됩니다. 사용자 입장에서는 첫 실행 때 진행률 표시줄이 하나 추가되는 것 말고는 처음 겪는 경험이 지금과 같습니다.
앱이 제공하는 전역 명령은 정적이어야 하며 앱 자체에 포함되어 있어야 합니다. 이 명령은 런타임에 동작을 바꾸는 것만 가능하며, 사용자가 직접 하는 경우(그리고 그 경우에도 설치된 다른 앱으로만)를 제외하고는 다른 실행 파일로 리디렉션될 수 없습니다. 따라서 PyManager가 제공할 명령은 python.exe, python3.exe, py.exe, pymanager.exe입니다. 이 명령들은 각각 사용자의 시스템을 검사하여 실행할 올바른 런타임을 선택할 수 있어야 합니다. 또한 py와 pymanager에는 런타임을 추가하고 제거할 수 있는 관리용 하위 명령이 있습니다.
PEP 394 및 Windows의 기본 동작에 맞추어, Python을 실행하는 권장 명령은 python.exe입니다. PyManager가 제공하는 이 명령은 PyManager가 관리하는 설치 중에서 찾거나 PEP 514를 이용해 기존 설치를 찾습니다. 그렇지 않으면 사용 가능한 최신 버전의 CPython을 설치하고 그 버전을 선택합니다. python3.exe 명령도 비슷하게 동작하지만, python.org에서 배포한 3.x 설치만 찾을 수 있습니다.
PyManager가 제공하는 py.exe 명령은 간결해서 대부분의 관리 작업에 권장됩니다. py install ..., py list ... 등이 그 예입니다. 제안하는 명령은 뒤에서 자세히 설명합니다. 기존 PEP 397 런처의 동작은 유지되지만, py를 통해 실행하면 (기본적으로) 런타임이 자동으로 설치되지 않습니다. 요청한 런타임이 설치되어 있지 않으면 사용자에게는 오류만 표시됩니다. 그러나 py exec ... 하위 명령은 런타임을 자동으로 설치하며, 단독 py와 같은 옵션을 지원합니다.
이 명령들은 OS가 사용자의 PATH에 매우 낮은 우선순위로 추가합니다. 우리가 사용자의 컴퓨터에 만들었을 수 있는 기존 구성은 모두 이 명령들보다 우선합니다. 따라서 이 명령들은 오류 메시지를 대신하는 최후의 수단입니다. 따라서 사용자가 이 명령들을 실행한다면 대개 더 우선하는 설정을 구성하지 않았기 때문이라고 가정할 수 있습니다(예를 들어, 환경을 활성화하면 다른 python.exe가 앞에 놓이므로 환경을 활성화한 사용자는 우리의 python.exe를 실행하는 일이 없습니다. 또한 기존 py.exe의 동작을 그대로 원하는 사용자는 그것을 설치하기만 하면 되므로 우리의 새 명령을 실행하는 일이 없습니다).
pymanager.exe 명령은 모호한 상황에 대처하기 위한 것입니다. 기존에 설치된 Python과 런처가 python.exe와 py.exe를 가릴 수 있고, 자동화된 환경에서는 이 때문에 관리 스크립트를 신뢰하기 어려워질 수 있습니다. pymanager 명령은 PyManager가 아닌 다른 것을 가리킬 가능성이 낮으므로 이런 경우에 사용할 수 있습니다. 이 명령에는 모든 하위 명령이 있으며, 명령을 지정하지 않고 실행하면 사용자에게 도움말을 출력합니다.
다른 설치 프로그램 대체
우리는 개별 버전을 Windows Store에 게시하는 일을 즉시 중단할 계획입니다. 또한 기존 설치 프로그램은 폐지 예정(deprecated)으로 지정하고 Python 3.16까지 단계적으로 없앨 계획입니다. 임베더블 배포판은 유지됩니다. 다만 python.org 다운로드 페이지에서는 단계적으로 빠지며, 이후에는 PyManager를 통해서만 받을 수 있습니다. NuGet 패키지는 변경되지 않습니다.
PyManager는 python.org에서 직접 내려받을 수 있는 앱 패키지로 제공되며, 더블 클릭으로 설치하는 과정은 대체로 매끄럽습니다. 이 방식은 현재 우리 사이트에서 내려받는 방식을 대신합니다. 이 패키지에는 최신 CPython(버전은 특정하지 않음)이 함께 들어 있습니다. 따라서 내려받은 파일을 인터넷에 연결되지 않은 컴퓨터로 옮겨 설치해도 Python 런타임을 사용할 수 있습니다.
일부 자동 배포 시나리오에서는 더 새로운 MSIX 형식을 사용할 수 없으므로, python.org에서 간단한 MSI도 제공합니다. 이 MSI에는 옵션이나 사용자 인터페이스가 없으며 관리자 권한이 필요합니다. 이러한 시나리오에서는 대개 관리자 권한을 사용할 수 있습니다. 또한 Wine처럼 MSIX 형식을 지원하지 않는 비표준 시스템의 사용자에게는 MSI가 필요합니다. 공식적으로 지원하지는 않지만, 이러한 플랫폼에서도 MSI를 통해 CPython의 업스트림 배포판을 계속 사용할 수 있습니다. 그 밖의 대부분의 사용자에게는 MSI를 권장하지 않으며, MSIX를 기본으로 간주합니다.
MSI 설치를 MSIX와 완전히 호환되게 만들 방법은 없습니다. 따라서 둘 다 설치한 사용자는 혼란이나 문제를 겪을 가능성이 높다는 점에 유의해야 합니다. Store 앱을 지원하지 않는 환경의 사용자만 MSI를 사용할 것으로 예상합니다.
우리의 릴리스 프로세스는 python.org에 일반 ZIP 패키지도 게시하기 시작합니다. 이 패키지는 FTP 페이지에서 받을 수 있지만, 일반 다운로드 페이지에는 직접 나열되지 않습니다.
현재 CPython을 직접 빌드해서 배포하는 서드파티 도구도 우리의 빌드를 얼마든지 사용할 수 있습니다. 다만 지원이 필요한 사용자에게는 해당 도구가 1차 연락 창구가 되어야 합니다.
프로젝트 소유권과 개발
PyManager는 CPython 저장소와 나란히 있는 별도의 저장소에서 CPython과 같은 조건으로 개발 및 유지 관리됩니다. CPython CLA가 적용되며, 모든 코어 개발자가 커밋 권한을 가집니다. 코어 개발자가 아닌 사람은 커밋 권한을 가지지 않습니다.
PyManager 릴리스는 CPython 릴리스와 독립적입니다. 버전이 서로 일치하거나 릴리스가 동시에 이루어질 필요는 없습니다. 달리 정하지 않는 한, Windows 빌드 관리자를 맡은 사람이 PyManager 릴리스 관리자가 됩니다.
명세
Note
이 문서에서는 모든 명령줄 옵션을 하이픈 한 개 또는 두 개와 함께 표시합니다. 구현에서는 Windows와 UNIX의 관례를 모두 허용하기 위해 모든 옵션이 하이픈 한 개나 두 개, 또는 슬래시를 지원합니다.
Exec 하위 명령
py [-V:<TAG>] [interpreter opts] [script.py|-m module|-c code] [script args]
py [-3.*] [interpreter opts] [script.py|-m module|-c code] [script args]
python ...
python3 ...
pymanager exec -V:tag ...
pymanager exec -3.* ...
이 하위 명령은 런타임을 선택하고 실행하는 데 사용됩니다. 이는 py 명령의 기본 동작이며, python 및 python3 명령이 지원하는 유일한 동작입니다. 이러한 명령의 기존 사용 방식과 일관성을 유지하기 위해 기본 옵션은 경우마다 미묘하게 다릅니다.
이 하위 명령은 py와 pymanager 모두에서 사용할 수 있습니다. 그러나 py는 이를 기본으로 제공하므로, 사용자가 py에서 이 하위 명령을 직접 사용하리라고는 예상하지 않습니다. py, python, python3 명령이 런타임을 실행하는 기본 방법이 되고, pymanager exec는 고급 시나리오용이 되도록 하는 것이 의도입니다.
-V:tag 명령은 명령줄에서 특정 런타임을 요청하는 데 사용됩니다. 태그는 Company\\Tag 쌍이거나, 슬래시가 포함되지 않은 경우에는 Tag만으로 이루어지며, PEP 514에 정의된 대로 사용됩니다. -3.* 옵션은 -V:PythonCore\\3.*로 해석됩니다. 이 옵션은 py 및 py exec 변형에서만 사용할 수 있습니다.
명령줄에 태그가 지정되지 않았고 스크립트 파일이 지정된 경우, 해당 스크립트에 셔뱅이 있는지 검사합니다. 인식된 패턴과 일치하는 셔뱅이 발견되면, 그 셔뱅은 검색에 사용할 태그를 제공하거나, 다른 모든 처리를 무시하고 추가 작업 없이 지정된 실행 파일을 실행하게 합니다. 이는 원래 이식성을 위한 기능으로 의도된 곳에 임의의 Windows 전용 경로를 허용해 온 (안타까운) 레거시 지원을 처리하기 위한 것입니다. 일반적으로 /usr/bin/python3.13과 같은 단순한 패턴을 포함하는 셔뱅을 염두에 둔 것이며, /usr/bin/env python을 사용하는 셔뱅은 환경이 자체 검색보다 신뢰성이 떨어지는 경향이 있으므로 도움이 될 가능성이 낮습니다.
아직 태그가 요청되지 않았다면, 환경이 활성화되었는지 확인하기 위해 VIRTUAL_ENV 환경 변수를 참조합니다. 활성화되어 있다면, 그 환경이 요청이 됩니다.
이 단계에서 태그가 요청된 경우, python3 명령은 해당 태그가 PythonCore\\3.*와 일치하는지 확인하고, 일치하지 않으면 오류와 함께 종료합니다. 이를 통해 다른 플랫폼과 일관되게 활성 환경에서 python3 명령을 사용할 수 있지만, 해당 환경에 이 명령이 포함되지 않았을 경우에는 사용할 수 없습니다. 이는 Windows에 있는 기존 Python 버전 대부분에 해당합니다. (이 동작 대신 택할 수 있는 방법은 환경이 활성화되어 있을 때 python3가 항상 오류를 내도록 하는 것입니다. 그 밖의 방식은 모두 사용자에게 일관되지 않게 동작할 것이기 때문입니다.)
태그가 요청되지 않았다면, 기본값을 참조합니다. python3의 경우 이 값은 PythonCore\\3이지만, 그 밖의 모든 명령에서는 구성에서 읽어 옵니다(환경 변수가 관여할 수도 있습니다). 그래도 비어 있다면, 어떤 태그든 허용합니다.
그런 다음 태그와 일치하는 설치된 런타임 중 가장 적합한 것을 선택하여 나머지 명령줄과 함께 실행합니다.
일치하는 런타임을 찾지 못하면 py exec 및 pymanager exec 명령은 (사용자 구성이 허용하는 경우) 런타임을 자동으로 설치하고 실행합니다. py, python, python3 명령은 오류를 보고하고 종료합니다. 그러나 다른 설치 프로그램에서 감지된 런타임까지 포함하여 사용할 수 있는 런타임이 전혀 없는 경우에는 첫 번째 런타임이 자동으로 설치됩니다. 이를 통해 유용한 첫 실행 경험을 제공합니다. PyManager를 막 설치한 새 사용자는 최신(또는 요청한) 버전의 CPython을 바로 실행하게 됩니다. 이 첫 실행 이후에는 요청한 런타임을 찾지 못하면 다시 오류가 보고됩니다.
install 하위 명령
py install [-s|--source <URL>] [-f|--force] [-u|--upgrade] tag [...]
py install [-s|--source <URL>] [-t|--target <DIR>] tag
py install [-s|--source <URL>] [-d|--download <DIR>] tag [...]
py install --refresh
Note
이 하위 명령과 이후의 모든 하위 명령은 pymanager 명령으로도 사용할 수 있습니다. 그러나 py를 일반적인 명령으로 사용하도록 의도하고 있으므로, 여기서는 그 명령만 보여 줍니다.
이 하위 명령은 현재 컴퓨터에 하나 이상의 런타임을 설치합니다. 태그는 Company\\Tag 쌍(슬래시가 없으면 Tag만)이며, 색인 파일을 검색하는 데 사용됩니다. 회사 이름은 대소문자를 구분하지 않는 접두사로 일치시키며, 접두사 일치보다 완전 일치를 우선합니다. 태그는 대소문자를 구분하지 않고 숫자를 인식하는 방식으로 일치시키며, 점으로 구분된 숫자는 버전으로 취급합니다. 이 방식은 축약된 요청을 처리해야 하는 사용 사례를 지원합니다. 태그는 나열된 “install for” 태그 중 하나와 일치해야 하며, 축약된 요청을 처리할 수 있도록 각 항목에는 이러한 태그가 여러 개 나열됩니다. 특수 태그 default는 사용자가 구성한 기본값(일반적으로 3입니다. 설정 구성에 대한 자세한 내용은 뒤의 구성 절을 참조하십시오)으로 해석됩니다.
태그는 >, >=, <, <= 또는 != 뒤에 Company\\Tag 또는 Tag 값을 붙여 제약 조건으로 지정할 수도 있습니다. 제약 조건을 일치시킬 때는 비교에 기본 태그 메타데이터만 사용합니다. 비교는 버전을 인식하므로, >3.10 같은 제약 조건은 최소 3.11을 선택하는 반면 >3.10.0은 3.10.1을 선택할 수 있습니다.
임의의 태그에 대한 제약 조건의 동작은 경우에 따라 직관에 맞지 않을 가능성이 큽니다. 제약 조건은 주로 일반적으로 버전 형태의 태그를 사용하는 업스트림 릴리스에 사용되며, 특히 Requires-Python 같은 다른 메타데이터를 처리하는 경우에 사용될 것으로 예상합니다. 사용자는 편의상 범위보다는 더 짧은 태그를 사용할 것으로 예상합니다.
기본 색인 파일은 python.org에서 호스팅되며, 설치 가능한 모든 버전의 패키지 URL과 해시를 포함한 설치 정보를 담고 있습니다. 사용자는 설정 파일이나 --source 명령줄 옵션을 사용하여 대체 색인을 지정할 수 있으며, 관리자는 설정 파일을 통해 지정할 수 있습니다. 요청된 태그를 색인 파일과 대조하여, 정확히 일치하는 항목을 찾으면 해당 패키지를 선택합니다. 정확히 일치하는 항목이 없으면 접두사 일치를 사용합니다. 두 경우 모두 태그의 숫자는 논리적으로 처리됩니다. 즉, 3.1은 3.1.2의 접두사이지만 3.10의 접두사는 아닙니다. 색인 파일에서 설치 태그를 정확히 어떻게 지정하는지에 대한 정보는 아래의 색인 스키마 절을 참조하십시오.
기존 설치가 이미 태그를 충족하면 아무것도 설치하지 않습니다. 기존 설치를 교체하려면 사용자가 --upgrade 또는 --force 옵션을 전달해야 합니다. 전자는 더 새로운 버전으로만 교체하고, 후자는 같은 버전이라도 제거한 뒤 교체합니다.
태그를 제공하지 않고 명령을 호출하면 아무것도 설치하지 않으며, (다른 잘못된 옵션과 마찬가지로) 도움말 텍스트와 오류를 표시합니다. 그러나 태그 없이 --upgrade를 전달하면 모든 설치를 업그레이드하려고 시도합니다.
--refresh를 전달하면 모든 설치의 메타데이터와 바로 가기를 다시 생성합니다. 바로 가기의 우선순위 결정은 모든 설치가 일관된 상태인 것에 의존하므로, 이 작업은 의도적으로 모든 설치에 한꺼번에 적용됩니다(예를 들어 최신 3.x 버전이 python3.exe 바로 가기를 가져야 하는데, 사용자가 이전 설치만 새로 고치도록 선택할 수 있다면 이 작업이 복잡해집니다).
태그 하나만 지정하여 --target <DIR> 옵션을 전달하면, 해당 런타임은 설치로 등록되지 않고(별칭이나 바로 가기도 생성되지 않고) 지정된 디렉터리에 추출됩니다. 이는 임베딩하는 경우나 호환되지 않는 플랫폼용 파일을 다운로드하는 경우를 지원하기 위한 것입니다. --target과 함께 여러 태그를 전달하면 오류가 발생합니다.
--download <DIR> 옵션을 전달하면 런타임 패키지를 다운로드하지만 설치하지는 않습니다. 런타임 패키지는 원본 패키지 형태로 지정된 디렉터리에 저장되며, 이 파일들을 참조하는 index.json이 생성됩니다. 이 색인은 나중에 python install --source <index.json> [tag ...]로 오프라인 설치를 수행하는 데 사용할 수 있습니다.
uninstall 하위 명령
py uninstall [-y|--yes] [--purge] [tag ...]
이 하위 명령은 현재 컴퓨터에서 하나 이상의 런타임을 제거합니다. 태그는 접두사 일치를 포함하여 install 명령과 똑같이 동작하지만, 기존 설치만 검사합니다. --yes 옵션을 전달하지 않으면 각 런타임을 제거하기 전에 사용자에게 확인을 요청합니다.
태그 없이 --purge 옵션을 전달하면 (확인을 거친 후) 모든 런타임이 바로 가기 및 캐시된 파일과 함께 제거됩니다. --purge와 함께 태그를 전달하면 오류가 발생합니다.
PyManager를 제거해도 설치된 런타임은 제거되지 않습니다. 기술적인 이유로 이를 안정적으로 수행할 수 없으므로(제거 시점에 임의의 코드를 실행할 수 없습니다), 대신 설치된 모든 항목이 계속 동작하도록 의도적으로 보장합니다. PyManager를 다시 설치하면 이러한 설치를 다시 관리할 수 있습니다. PyManager를 제거하기 전에 py uninstall --purge를 실행하면 완전히 제거됩니다.
list 하위 명령
py list [-f|--format <FMT>] [-1|--one] [--only-managed] [tag ...]
py list [-f|--format <FMT>] [-1|--one] [--online] [--source <URL>] [tag ...]
py [--list|--list-paths|-0|-0p]
이 하위 명령은 지정된 태그나 범위와 일치하는 설치를 일부 또는 전부 나열합니다. 태그를 지정하지 않으면 모든 설치를 나열합니다. PyManager가 관리하지 않는 런타임(활성화된 가상 환경 포함)은 따로 나열될 수 있습니다.
기본 형식은 사용자 친화적입니다. 다른 형식으로는 기계가 읽을 수 있는 형식과 단일 문자열 형식이 있습니다(예: --format=prefix는 sys.prefix만 한 줄에 출력합니다). 정확한 형식 목록은 구현에 맡깁니다.
--one을 지정하면 가장 적합한 결과 하나만 나열합니다. 이는 기본(또는 적절한) 런타임을 실행하지 않고 그 위치를 찾으려는 셸 스크립트를 돕기 위한 것입니다. (“가장 적합한”의 정의는 느슨하지만, 사용자가 선호하는 기본 환경이 결과에 포함되어 있다면 항상 그 환경이 선택됩니다.)
--only-managed 옵션은 발견되었지만 PyManager가 관리하지 않는 런타임(예: 일반적인 PEP 514 조회로 찾은 런타임)을 제외합니다.
--source를 전달하면(또는 기본 소스를 암묵적으로 전달하는 --online을 전달하면) 현재 설치된 런타임 대신 온라인 색인을 검색합니다. 이 옵션을 install 하위 명령이 아닌 여기에 두는 이유는 필터링 및 형식 지정 옵션이 이미 list에 있기 때문입니다.
py.exe 런처의 기존 --list, --list-paths, -0, -0p 인자도 제공됩니다. 하지만 이 인자들은 여기에 나열된 새 옵션을 지원하지 않으며, 기존 런처의 출력을 재현하는 데 그칩니다. 이 목록에서는 관리되지 않는 설치를 구별할 수 없습니다.
help 하위 명령
py help <COMMAND>
이 하위 명령은 지정한 각 명령의 도움말 텍스트를 표시하며, 명령을 지정하지 않으면 명령 목록을 보여 줍니다. 명령 하나를 지정하는 것은 py <COMMAND> --help와 같습니다. 하위 명령 목록을 보여 주는 것이 pymanager 명령의 기본 동작입니다.
이 명령은 주로 사용자에게 더 많은 정보를 찾는 방법을 간단하게 안내하기 위해 추가되었습니다. 사용자에게 py help를 실행하라고 안내하면 됩니다. 이렇게 하면 python -? 출력을 재정의하거나 확장할 필요가 없습니다. 이 출력은 따로 처리하지 않으면 선택된 런타임으로 전달되며, 이미 적어도 한 화면 분량의 텍스트를 출력합니다.
자동 설치 후(예: 아무것도 설치되지 않은 상태에서 python을 실행한 경우), 설치를 관리하는 방법에 대한 자세한 정보를 보려면 py help를 실행하면 된다고 알려 주는 메시지가 표시됩니다.
환경 변수
스토어 앱을 설치할 때는 어떤 환경 변수도 자동으로 갱신할 수 없으므로, 자동으로 갱신하지 않습니다. 정상적으로 동작하는 컴퓨터라면 핵심 명령은 이미 사용할 수 있어야 합니다.
사용자의 PyManager 데이터 디렉터리 안에 있는 디렉터리 하나를 생성된 별칭용으로 따로 둡니다. 원한다면 사용자가 이 디렉터리를 직접 PATH에 추가할 수 있습니다. 이 디렉터리의 내용은 PyManager가 관리하며, 설치된 런타임을 직접 실행하는 실행 파일이 들어 있습니다(예를 들어, Python 3.13을 설치했다면 python3.exe와 python3.13.exe가 들어 있습니다). 이 디렉터리에 별칭이 추가될 때마다 PATH를 검사하며, 이 디렉터리가 빠져 있으면 추가할 경로가 담긴 메시지를 사용자에게 보여 줍니다.
런타임에 설치된 패키지가 설치하는 스크립트는 또 다른 디렉터리에 들어갑니다. 현재 설계상, 이 스크립트들을 모두 한 디렉터리나 여러 런타임이 공유하는 디렉터리에 설치하는 것은 안전하지 않다고 판단합니다. 다만 향후에는 PyManager가 설치된 패키지의 메타데이터를 바탕으로 자체 진입점을 생성하는 명령이 추가될 수도 있습니다.
시작 메뉴 바로 가기
사용자의 기본 웹 브라우저에서 PyManager 문서를 여는 시작 메뉴 바로 가기가 추가됩니다. 시작 메뉴에 애플리케이션은 추가되지 않습니다.
Python 런타임을 설치할 때, 설치 정의에서 해당 설치에 대해 만들 시작 메뉴 바로 가기를 지정할 수 있습니다.
파일 연결
PyManager를 설치할 때 표준 파일 연결이 생성되며, 이 연결은 PyManager의 전역 python.exe 별칭으로 스크립트와 패키징된 앱을 실행합니다. 이를 통해 스크립트나 .pyz 파일을 더블 클릭하는 사용자에게 합리적인 동작을 제공합니다.
창 모드 실행 파일
앞에서 설명한 각 전역 별칭마다 *w.exe도 존재합니다. 이 실행 파일들은 콘솔 창을 만들거나 연결하지 않고 실행되므로, 일반적으로 스크립트가 만든 UI만 표시합니다. 예를 들어, IDLE은 불필요한 네이티브 콘솔을 피하기 위해 항상 pythonw.exe를 사용하여 실행됩니다.
그 밖의 점에서 이 명령들은 대응하는 콘솔용 명령과 똑같이 동작합니다.
구성
PyManager는 JSON 기반 설정 파일의 계층 구조를 사용하여 설정됩니다. 명령줄 옵션은 항상 설정 파일 옵션보다 우선합니다. 사용자가 편집할 수 있는 위치에 있는 설정 파일은 설정이나 명령줄 옵션으로 비활성화할 수 있습니다.
우선순위가 낮은 것부터 높은 순으로 다음 위치에서 찾습니다:
- 앱 패키지 내부
- 관리자 전용 구성으로 지정된 위치(아래 참조)
base_config설정에 지정된 위치(기본값: 없음)user_config설정에 지정된 위치(기본값:%AppData%\\Python\\PyManager.json)additional_config설정에 지정된 위치(기본값:%PYTHON_MANAGER_CONFIG%)-c명령줄 옵션으로 지정된 위치
각 구성 옵션의 구체적인 동작은 구현에 맡깁니다. 다만 의도된 여러 옵션은 다른 절에서 논의합니다.
앱 패키지 구성은 PyManager를 다른 애플리케이션이나 패키지에 내장할 수 있도록 제공됩니다. 예를 들어, 대체 배포판에서 PyManager를 포함하되 자체 색인에서 설치 항목을 찾도록 하고 싶을 수 있습니다. 앱 패키지 구성을 사용하면 저희 빌드를 재사용하면서 기본 설정을 재정의할 수 있습니다.
user_config와 additional_config 설정은 앞선 설정 파일에서 미리 설정되므로, 관리자 전용 설정이나 대체 루트 설정으로 재정의할 수 있습니다. 설정 파일이 자신을 불러오게 한 설정을 덮어쓰면, 그 덮어쓰기는 무시됩니다. base_config 설정도 비슷하지만, 빈 상태로 시작하며 관리자 구성을 통해 쉽게 재정의할 수 있도록 하기 위한 것입니다.
관리자 전용 구성은 관리자가 그룹 정책이나 레지스트리 업데이트 같은 기존 도구를 사용하여 자신이 관리하는 시스템을 관리할 수 있도록 제공됩니다. 이러한 제어는 설계상 재정의할 수 없으므로, 관리자는 PyManager의 사용을 막거나 제한하는 정책을 배포할 수 있습니다. 이러한 제어는 PyManager를 특정 환경에 안전하게 배포하는 데 필수적이며, 이것이 없다면 PyManager는 아예 허용되지 않아 해당 사용자들은 Python을 전혀 사용할 수 없게 됩니다.
주된 관리자 전용 설정은 관리자가 통제하는 임의의 위치에 배포할 수 있는 새 base_config 설정 파일의 경로가 되도록 하는 것이 의도입니다. 이를 통해 네트워크 관리자는 사용자를 강제로 제한하지 않으면서 사용자의 기본 Python 런타임 출처를 통제하거나, (명령줄 옵션을 제외한) 설정 파일의 다른 출처를 재정의할 수 있습니다.
색인 스키마
색인 파일은 온라인 또는 로컬로 제공되며, PyManager가 모든 Python 런타임을 찾고, 선택하고, 설치하고, 관리하는 데 필요한 모든 정보를 제공합니다.
색인은 JSON으로 저장됩니다. 주된 최상위 키는 versions이며, 객체 목록을 담고 있습니다. 각 버전 객체는 자체 스키마 버전을 가지며, 파일 전체에 대한 스키마 버전은 없습니다. 향후 변경에서는 기존 키에 안전하게 통합할 수 없는 기능을 제공하기 위해 최상위 키를 추가할 수 있습니다.
버전 객체는 색인 파일과 각 패키지 아카이브의 루트에 저장된 __install__.json에 나뉘어 있을 수 있습니다. 번들 파일의 항목은 색인 파일에서 빠진 부분을 채웁니다. 이는 일반적으로 크기가 큰 shortcuts 키를 색인 파일에서 제거할 수 있도록 하기 위한 것이지만, alias, executable, executable_args에도 적용될 수 있습니다. 색인에서 다른 키를 생략하면 패키지 설치에 문제가 생길 수 있습니다. 올바른 동작을 보장하는 것은 구현에 맡깁니다. 이는 상호 운용성에 관한 사항이 아니므로, 여기에서는 (적용되는 일반적인 호환성 요구 사항 외에는) 세부 사항을 명시할 의도가 없습니다.
두 번째 최상위 키인 next에는 다른 색인을 가리키는 URL을 선택적으로 넣을 수 있습니다. 포함된 버전 중에서 PyManager가 적합한 패키지를 찾지 못하면 이 URL을 사용할 수 있습니다. 이렇게 하면 오래된 색인은 보관해 두었다가 필요할 때만 접근할 수 있습니다. 그 결과 사용자는 이전 버전을 계속 사용할 수 있고, 처음 내려받는 크기는 줄어듭니다. 적합한 설치 대상을 검색할 때 쓸 만한 후보를 찾으면 그 뒤의 색인은 검색하지 않습니다(다시 말해, 가장 먼저 조회하는 색인에 최신 버전이 들어 있어야 합니다).
초기 스키마는 다음과 같습니다:
SCHEMA = {
"versions": [
{
# Should be 1.
"schema": int,
# Unique ID used for install detection/side-by-side.
# Must be valid as a filename.
"id": str,
# Name to display in the UI
"display-name": str,
# Version used to sort packages. Also determines prerelease status.
# Should follow Python's format, but is only compared among releases
# with the same Company.
"sort-version": Version,
# Specifies platforms to consider this package for.
# Initially, 'win32' is the only supported value. Others may be
# defined in the future. This condition is evaluated silently, and
# is not intended to replace platform requests in "install-for".
"platform": [str],
# Company field, used for filtering and displayed as the publisher.
"company": str,
# Default tag, mainly for UI purposes.
# It should also be specified in 'install-for' and 'run-for'.
"tag": str,
# List of tags to install this package for. This does not have to be
# unique across all installs; the first match will be selected.
# For example, the 3.10.5 package may list '3', '3.10' and
# '3.10.5' so that any of those may be specified to install it.
# Matches are number aware, so that 3.1 is not a prefix of 3.10.
"install-for": [str],
# List of tags to run this package for. Does not have to be unique
# across all installs; the first match will be selected. The target
# is the executable path relative to the root of the archive.
# Explicit args (optional) are inserted before user args.
"run-for": [{"tag": str, "target": str, "args": [str], "windowed": int}, ...],
# List of global CLI aliases to create for this package. Does not
# have to be unique across all installs; the first match will be
# created.
"alias": [{"name": str, "target": str, "windowed": int}, ...],
# List of shortcuts to create for this package. Additional keys on
# each instance are allowed based on the value of 'kind'.
# Initially, 'kind' supports the following values:
# * 'pep514' - other keys define registry values to set
# * 'start' - generate shortcuts in the user's Start Menu
# * 'uninstall' - generate an Add/Remove Programs entry
"shortcuts": [{"kind": str, ...}, ...]
# Default executable path, relative to the root of the archive.
# Usually the values from 'run-for' will be used instead, and this
# is mainly for display purposes.
"executable": str,
# Default executable args
"executable_args": [str],
# URL to download the package archive from
"url": str,
# Optional set of hashes to validate the download. Hashes are stored
# as hex digests. Any hash supported by hashlib without OpenSSL is
# permitted.
"hash": {
"<hash_name>": str,
}
}
],
# URL (or relative path) to the next index file
"next": str,
}
셔뱅 처리
PyManager는 sh 계열 셸용으로 작성된 스크립트와 제한적으로 호환되도록 스크립트에 셔뱅 줄이 있는지 확인합니다. 셔뱅 줄에 Python 명령이 지정되어 있으면 (명령줄에서 재정의하지 않은 경우) 그 줄을 사용해 스크립트에 적합한 런타임을 선택합니다.
현재 py.exe 런처의 지원 방식과 달리, 이 기능을 줄일 것을 제안합니다. 설치에 등록된 전역 별칭과 일치하는 Python 명령만 지원하고, 일치하지 않는 것은 모두 임의의 실행 파일 경로로 취급합니다. 억지로 만든 경우가 아니라면 실제 결과는 지금과 같거나 더 나을 것으로 예상합니다. 다만 사용자가 기존 런처의 명시되지 않은 경계 사례 동작에 의존하고 있었다면 미묘한 변화가 생길 수 있습니다.
감지할 구체적인 패턴은 구현에 맡기지만, 기존 런처와 대체로 호환되어야 합니다.
근거
python.exe 명령 “변경”
PyManager가 제공하는 전역 python.exe 별칭은 “진짜 Python이 아니므로” 다른 이름을 써야 한다는 주장이 있을 수 있습니다. 엄밀히 따지면 맞는 말이지만, 그래도 이 이름을 써야 한다고 보는 이유가 세 가지 있습니다.
첫째, 매일 수천 명의 사용자가 새 컴퓨터의 터미널에 python을 입력했다가 스토어 페이지로 안내되고, 그곳에서 설치합니다. 이 리디렉션을 구현한 방식 때문에, 사용자가 설치한 앱이 python 명령을 제공하지 않으면 리디렉션이 그대로 남습니다. 사용자가 계속 스토어로 되돌아가는 상황에 갇히지 않게 하려면 이 명령을 제공해야 합니다. (python3에도 마찬가지로 적용됩니다.)
둘째, “진짜가 아닌” 별칭을 제공하지 않는다고 해서 “진짜” 별칭이 대신 생기는 것은 아닙니다. 아무것도 없게 될 뿐입니다. 전역 정적 별칭을 사용자의 선호나 설치 상태를 따르는 별칭으로 바꿀 방법이 없으므로, 다른 선택지는 아무것도 제공하지 않고 python이 어떤 경우에도 오류가 나게 두는 것입니다. 이는 더 나쁜 결과이며, 저희가 보기에는 Python의 평판에 적극적으로 해를 끼칩니다.
셋째, python 별칭의 내부 구현은 기본 Programs/python.c보다 복잡하지만, 사용하는 경험은 똑같습니다. 이 별칭은 사용자가 달리 선호를 밝히지 않은 경우(즉, PATH에 다른 것이 없는 경우)에만 실행됩니다. 또한 설정이나 셔뱅 같은 간접적인 선호를 모두 존중하며, 사용자 컴퓨터에서 쓸 수 있는 가장 적합한 버전의 Python을 실행합니다. 이는 다른 어떤 대안보다도 전역 python 명령에 기대하는 동작에 훨씬 가깝습니다.
Gentoo 역시 단순한 심볼릭 링크보다 사용자에게 더 나은 경험을 주려고 지능적인 python 명령을 배포한다는 점이 언급된 바 있습니다.
py.exe 대체
py.exe 런처는 PyManager가 그대로 구현할 기능 중 일부를 제공합니다. 구체적으로는 이미 설치된 런타임을 실행하는 기능입니다. 오랜 역사에도 불구하고 이 런처는 대부분의 사용자가 선호하는 방법이 되지는 못한 것으로 보입니다. 많은 사용자는 PATH 환경 변수를 전역으로 수정하는 방식을 선호합니다. 그러나 이 명령 자체에 의존하는 사용자가 생겼으므로 가능한 한 오래 유지해야 합니다. 이는 두 가지 방법으로 이루어집니다.
먼저, PyManager와 함께 자체 py.exe 별칭을 설치합니다. 이 별칭은 기존과 같은 기능에 더해 PyManager 고유의 기능도 제공합니다. 이 별칭은 시간이 지나면서 py.exe의 기본/권장 설치 방식이 되도록 의도되었습니다.
둘째, (요청이 있는 경우) 각 설치에 대해 PEP 514 메타데이터를 생성합니다. 이를 통해 레거시 py.exe도 PyManager가 관리하는 설치에서 계속 정상적으로 동작할 수 있습니다.
기존 py.exe 런처가 자신을 구성하는 방식과 PyManager의 MSIX 패키지에 적용되는 제약 때문에, PyManager의 py 별칭은 런처를 재정의할 수 없습니다. 그 결과, 런처를 설치한 사용자의 경우 py는 항상 런처로 연결됩니다. 결국 PyManager 쪽으로 이 문제를 해결하는 유일한 방법은 런처를 제거하는 것이며, 이는 표준 설치된 앱 제어판에서 할 수 있습니다.
기존 설치 프로그램과 함께 계속 릴리스될 기존 런처를 업데이트하여, 새 하위 명령의 사용 시도를 감지하고 현재의 오류 대신 사용자에게 유용한 메시지를 제공하도록 할 것을 제안합니다. 이러한 경고는 사용자가 해당 이름의 확장자 없는 파일을 의도적으로 실행하는 드문 경우도 감지하여 그 동작을 유지할 수 있으므로, 설정을 달리 변경할 수 없는 사용자에게 실행 가능한 대안을 제공합니다.
venv와의 상호 작용
표준 라이브러리 venv 모듈이 구현하는 가상 환경을 활성화하면, venv 런처가 다른 실행 파일보다 우선하도록 사용자의 PATH 환경 변수가 수정됩니다. 그 결과, venv가 활성화된 상태에서는 python을 제외한 다른 별칭으로만 PyManager를 실행할 수 있습니다. 활성화된 가상 환경이 감지되면 (제거를 제외하고) 그 가상 환경을 사용자의 기본 런타임으로 취급하므로, 다른 명령도 예상대로 동작합니다.
즉, 정상적으로 동작하는 가상 환경은 PyManager의 추가 지원 없이도 지금과 똑같이 동작합니다.
하위 호환성
일반적으로 마이너 버전 간(3.x에서 3.y로) 설치 과정에 대한 호환성은 보장되지 않으므로, “다른 설치 프로그램을 사용해야 하는 것”은 호환성을 깨뜨리는 것으로 간주하지 않습니다. 설치되는 Python 버전은 설치 방식이 그 동작을 바꾸었던 범위 안에서만 이 변경의 영향을 받습니다. 일반적으로 대부분의 설치는 사용자가 직접 소스에서 빌드한 경우의 동작에 더 가까워질 것입니다.
그렇지만 새 설치 과정으로 실제로 옮겨 갈 때 일부 사용자에게 영향을 줄 변경 사항이 여럿 있습니다. 이 절에서는 저희가 알고 있는 변경 사항을 특별한 순서 없이 가능한 한 많이 정리하며, 이 내용은 마이그레이션 가이드의 기초가 될 가능성이 높습니다.
스크립트를 통한 다운로드
기존 설치 프로그램의 다운로드 파일 이름을 생성하는 스크립트를 작성한 사용자는 그 스크립트가 더 이상 동작하지 않게 됩니다. 이러한 URL은 안정적이거나 예측 가능하다고 보장된 적이 없으므로, 저희로서는 사과드리고 다운로드에 저희가 제공하는 도구를 사용하도록 권하는 것 외에는 달리 할 수 있는 일이 없습니다.
기존 설치 프로그램의 폐지 예고 기간 동안 이러한 사용자는 다가오는 변경 사항을 알게 될 시간을 가질 수 있습니다. 가능한 경우 기존 설치 프로그램에 폐지 예고 경고를 추가할 것입니다.
스크립트를 통한 설치
특정 옵션으로 설치 프로그램을 실행하는 스크립트를 작성한 사용자는 스크립트를 변경해야 합니다. 우선 대부분의 옵션이 제거되었으며, 남아 있는 옵션도 표기가 새로 바뀌었습니다. 수동 개입 없이는 기존 설치 프로그램의 옵션이 새 설치 프로그램에 전달되는 상태에 이를 수 없으므로(즉, 누군가가 이미 명령을 변경해야 하므로), 이는 허용 가능한 변경으로 간주합니다.
기존 설치 프로그램의 폐지 예고 기간 동안 이러한 사용자는 다가오는 변경 사항을 알게 될 시간을 가질 수 있습니다. 가능한 경우 기존 설치 프로그램에 폐지 예고 경고를 추가할 것입니다.
설치된 이전 런타임
이미 런타임을 설치한 사용자의 경우, 등록 정보가 손상되지 않았다면 PyManager와 그 별칭이 해당 런타임을 선택합니다.
설치된 런타임 간의 우선순위 순서가 변경되어, 명시적으로 요청한 경우에만 사전 릴리스 버전을 포함하고(예를 들어, -V:3은 3.15.0a1이 아닌 3.14.0과 일치하지만, -V:3.15는 3.15.0a1과 일치합니다), 태그의 텍스트 접미사를 올바르게 정렬합니다(예를 들어, 이제 3.14t는 3.14보다 우선순위가 낮습니다).
이 변경이 사용자에게 영향을 줄 수 있는 경우에 경고를 제공하는 것도 가능하지만, 그러한 경고는 매우 성가신 것으로 여겨질 것이며(예: 선택되지 않은 사전 릴리스가 설치되어 있다는 이유로 python을 실행할 때마다 메시지가 표시됨), 선택 로직을 불필요하게 복잡하게 만들어야 합니다. 이 변경 사항은 문서화만 합니다.
이전 py.exe 런처가 설치된 경우
이전 py.exe 런처를 수동으로 제거하지 않은 사용자는 기존 Python 설치와 새 Python 설치가 모두 발견되지만, 버전이 일치하는 경우에는 기존 설치가 새 설치보다 우선한다는 것을 알게 될 것입니다(반면 새 py는 새 설치를 선택합니다).
또한 py list와 같은 명령이 작동하지 않는다는 것도 알게 될 것입니다. 이에 대한 해결책은 Windows 설정을 사용하여 런처를 제거하는 것입니다.
사용자가 실수로 이전 py를 설치된 채로 남겨 두었는지 감지하거나, 사용자 대신 이를 제거할 방법은 없습니다. 이 변경 사항은 문서화만 합니다.
잘못 구성된 venv가 활성화된 경우
python.exe가 없거나 PATH에 포함되어 있지 않은, 손상되었거나 잘못 구성된 가상 환경을 활성화한 사용자는 이전과 다른 오류를 받을 수 있습니다.
대신 PyManager의 전역 python 별칭이 발견되어 실행되며, 시스템의 “찾을 수 없음” 오류는 모두 표시되지 않습니다. 이 별칭은 해당 환경의 실제 런타임을 찾지 못하므로 결국 실패하게 되지만, 코드와 메시지는 다를 수 있습니다.
이 시나리오는 이미 손상된 시스템을 전제로 하므로, 이 변경 사항은 문서화만 합니다.
이전 버전의 가용성
PyManager의 첫 릴리스 이전의 Python 버전은 새로 재패키징한 아카이브를 기반으로 하거나 NuGet의 거의 동등한 패키지를 사용하여 python.org 색인에 소급하여 추가할 수 있습니다(후자는 Tcl/Tk를 포함하지 않아 일부 사용자에게는 호환성이 크게 떨어지지만, 특히 오래된 버전에서는 아마 괜찮을 것입니다).
이 PEP가 수락된 시점을 기준으로, 지원이 종료되지 않은 모든 릴리스를 PyManager로 완전히 설치할 수 있도록 Python 3.10.0 이후의 모든 버전(패치 릴리스는 포함하되 사전 릴리스는 제외)에 대한 패키지를 만들 계획입니다. Python 3.5.0 이후의 버전(사전 릴리스 제외)은 NuGet의 패키지를 직접 참조하므로, 축소된 형태로 쉽게 사용할 수 있습니다. 두 방식 모두 기존 릴리스를 다시 빌드할 필요가 없으며, 해당 릴리스의 소스를 변경할 필요도 없습니다.
관리자 설치
PyManager는 사용자 자신의 디렉터리에만 설치하므로, 더 이상 모든 사용자를 위한 Python 사본을 설치할 수 없습니다. 머신 단위 설치가 업스트림 배포판에 대한 우리의 의도에 부합함을 보여 주는 시나리오가 제시된 적이 없으므로, 그에 대한 옵션은 제공하지 않을 것입니다. 이 기능을 원하는 서드파티는 자체 배포판을 제공하기를 권장합니다.
PyManager는 모든 사용자용으로만 설치할 수 있지만, MSIX는 설치하는 데 관리자 권한이 필요하지 않으며, 사용자가 설치할 수 있는 실제 런타임을 제한하는 것을 포함하여 관리자가 광범위하게 구성할 수 있습니다. 또한 PyManager는 번들링을 위한 로컬 추출을 지원하므로, 임베딩하는 앱은 자체 레이아웃을 쉽게 생성할 수 있으며, 원한다면 이를 모든 사용자용으로 설치할 수 있습니다.
이 시나리오는 변경 여부와 관계없이 관리자의 개입이 필요하므로, 문서화만 합니다.
빌드 시점 설치
임베더블 배포판을 사용하는 사용자는 패키지 URL을 찾는 새로운 방법으로 바꿔야 할 수도 있지만, 권장하는 방법은 PyManager를 사용하여 찾고 설치하는 것입니다. 설치 프로그램 변경으로 인한 차이는 없을 것으로 예상되며, 임베더블 배포판 패키지는 현재와 동일할 것입니다.
NuGet 패키지에 대한 변경은 제안하지 않습니다.
단일 아키텍처 설치 프로그램
현재 제안은 PyManager의 Intel 64비트 빌드만 제공합니다. 이로 인해 32비트만 지원하는 운영 체제나 CPU를 사용하는 사용자는 PyManager를 설치할 수 없게 됩니다. 오늘날 이러한 기기는 극히 적은 비율에 불과하고, PyManager의 대상 사용자층인 개발자 기기에서는 그 비율이 더욱 작으므로, 이들 사용자가 제외되는 것을 우려하지 않습니다.
Windows ARM64 기기는 효율적인 에뮬레이션을 통해 Intel 64비트용으로 빌드된 바이너리의 실행을 지원합니다. CPython 32비트 빌드는 64비트 바이너리로 대체할 수 없는 32비트 실행 파일과의 통합에서 중요한 역할을 하므로 계속 제공됩니다. PyManager는 독립 실행 파일로 실행되므로, 관리자에게는 이 기능이 필요하지 않습니다.
테스트 스위트와 디버그 심볼
기존 설치 프로그램에서는 Python 표준 라이브러리 테스트 스위트와 디버그 심볼을 선택적으로 설치할 수 있습니다. 두 가지 모두 대부분의 사용자에게는 필요하지 않지만, 일부 사용자에게는 편리합니다. 예비 테스트에 따르면 테스트 스위트와 디버그 심볼을 제외하면 압축된 패키지의 크기가 약 60% 줄어듭니다(46MB에서 18MB로).
따라서 PyManager가 설치하는 “기본” CPython 패키지에는 테스트 스위트나 디버그 심볼이 포함되지 않습니다. 하지만 이러한 추가 요소를 포함하는 두 번째 패키지 집합이 제공되며, 이 패키지들은 (기본값인 PythonCore와 달리) PythonTest 아래에 묶입니다. 예를 들어, py install 3.13이 기본 런타임을 설치하는 반면, py install PythonTest\\3.13은 추가 파일이 포함된 두 번째 런타임을 설치합니다(이 런타임은 py -V:PythonTest\\3.13으로 실행하거나, 동등한 PythonCore 버전이 설치되어 있지 않다면 간단히 py -V:3.13으로 실행할 수 있습니다).
디버그 바이너리는 더 이상 배포되지 않으며, 그 밖의 모든 선택 기능은 기본적으로 포함됩니다.
전역 pip 명령
현재의 Windows Store 설치와 달리 전역 pip 명령은 포함되지 않습니다(기존 설치 프로그램 역시 PATH를 수정하는 옵션과 pip를 설치하는 옵션을 선택하지 않는 한 전역 pip 명령을 포함하지 않으며, 이 중 첫 번째 옵션은 기본적으로 꺼져 있습니다). 이는 이미 권장되지 않는 패키지 전역 설치에 영향을 주지만, 활성화된 가상 환경에는 영향을 주지 않습니다.
pip를 실행할 때 python -m pip 또는 py -V:<TAG> -m pip를 사용하라는 기존 권장 사항은 그대로 유지됩니다.
보안 영향
이 절에서는 설치 프로그램 자체의 보안 영향을 기존 설치 프로그램과 비교합니다. 기기에 Python이 설치됨으로써 생기는 영향은 범위에 포함되지 않으며, 악의적인 사용자가 설치 프로그램을 실행할 수 있는지 여부 역시 범위에 포함되지 않습니다.
설치 프로그램이 일으키는 전형적인 위험은 권한 상승 상태의 설치가 시스템을 변경하여, 이후 낮은 권한의 사용자가 높은 권한의 사용자에게 영향을 줄 수 있게 되는 것입니다. 예를 들어 공유 폴더의 접근 제어를 부적절하게 설정하는 경우가 이에 해당합니다. PyManager는 사용자와 동일한 권한 수준으로만 동작하므로, 어떠한 권한 상승 경로도 만들어 낼 수 없습니다.
앞서 설명한 MSI를 사용한 설치는 오래된 설치 프로그램 기술을 사용하기 때문에 추가적인 위험을 초래할 수 있습니다. 일반 사용자는 안전한 MSIX 또는 Windows Store 설치 경로로 안내되며, MSI 사용자는 자신의 설치 과정의 보안을 스스로 보장할 수 있다고 가정합니다(예를 들어, 설치 프로그램을 실행하는 명령을 올바르게 따옴표로 묶고 초기 시스템 구성이 적절한지 확인하는 등).
기기에 PyManager가 설치되고 나면, 악의적인 사용자가 이를 이용해 Python을 설치할 가능성이 높습니다. 앞의 “Configuration”에서 설명한 관리자 전용 구성은 이러한 시나리오를 통제하기 위한 것입니다. 하지만 결국 PyManager를 실행할 수 있는 공격자는 사용자가 할 수 있는 모든 일을 할 수 있으며, 완전한 애플리케이션 허용 목록 방식만이 Python의 사용을 막을 수 있습니다.
HTTPS를 통한 패키지 획득은 연결 보안으로 보호됩니다. 공개 인증서와 엔터프라이즈 인증서, 그리고 인증된 프록시 서버를 지원하는 Windows 네이티브 다운로드 메커니즘을 사용합니다. 피드에는 다운로드 가능한 패키지의 해시가 포함될 수 있으며 이 해시는 검증되지만, PyManager에는 제3자가 호스팅하는 검증 기능이 내장되어 있지 않습니다. 이는 현재의 모델과 일치합니다.
PyManager로 설치한 런타임은 현재 사용자가 완전히 접근하고 수정할 수 있습니다. 이는 기존 설치 프로그램이나 NuGet 패키지를 사용하는 일반적인 설치와 같지만, Store 설치나 기존 설치 프로그램을 사용한 컴퓨터 전체(per-machine) 설치보다 변조에 더 취약합니다. 설치를 수행한 사용자로부터 해당 설치를 완전히 보호하는 것은 불가능합니다. 설치를 다시 하거나 업데이트하면 클린 설치가 수행되므로, 최초 설치 이후 발생했을 수 있는 모든 변조가 원래대로 되돌려집니다.
런타임을 설치할 때 PyManager가 생성하는 별칭은 서명되고 수정되지 않은 실행 파일을 사용하도록 설계되어 있으며, 이 실행 파일은 인접한 데이터 파일을 사용하여 올바른 대상을 실행합니다. 이를 악용하면 런처가 다른 대상을 실행하도록 쉽게 만들 수 있지만, 이를 해결하는 유일한 방법은 실행 파일 자체에 대한 신뢰를 희생하는 것이며, 그렇게 되면 데이터 대신 실행 파일을 교체하는 것이 아주 쉬워집니다. 이러한 위험은 이미 존재하며, 사용자가 실행할 수 있는 스크립트나 표준 라이브러리의 어느 부분이든 교체하는 것과 같습니다. 중요한 점은, 별칭이 사용자 간에 공유되지 않으므로 이 경로를 통한 권한 상승은 발생하지 않는다는 것입니다.
PyManager에는 컴퓨터 전체 설치를 수행하는 메커니즘이 없습니다. 이는 일부 사용자에게 유용한 기능일 수 있는데, 일반 사용자가 설치를 전혀 수정할 수 없게 만들 수 있기 때문입니다(가상 환경과 사용자 site 폴더는 제외). 관리자가 PyManager와 다른 OS 명령을 사용하여 이러한 기능을 수동으로 흉내 낼 수는 있지만, 이는 중요한 워크플로로 간주하지 않습니다. 권장되는 대안은 관리자가 PyManager를 제공하고 그 구성을 재정의하는 것입니다.
기존 PEP에 미치는 영향
이 제안은 같은 이름의 새 도구의 일부로 동일한 기능을 정의함으로써 PEP 397 (“Windows용 Python 런처”)와 PEP 486 (“Python 런처가 가상 환경을 인식하도록 하기”)을 사실상 대체합니다. 두 PEP 모두 이미 최종(final) 상태로 간주되며, 런처는 해당 문서와 일반적인 호환성 절차에 의해 정의됩니다. 새로운 기능은 원래의 PEP 본문이 아니라 현재 구현을 기반으로 합니다.
이 제안은 PEP 394(“The “python” Command on Unix-Like Systems”)에 영향을 미치지 않으며, 모든 플랫폼의 사용자에게 유사한 안내를 제공할 수 있는 Windows용 접근 방식을 고안한다는 점에서 해당 PEP와 일관된다고 판단됩니다.
이 제안은 PEP 514 (“Windows 레지스트리에 Python 등록하기”)에 아무런 영향을 주지 않으며, 오히려 우리 자신의 런타임을 등록하는 더 유연한 시스템을 통해 이 PEP를 따르는 능력을 향상시킵니다. PEP 514를 따르는 도구는 등록을 사용하기로 한 모든 런타임을 설치 방식과 관계없이 찾아냅니다.
교육 방법
기본 사용법
이 제안의 핵심 목표는 가장 기본적인 경우에 “터미널에 ‘python’을 입력하십시오”라는 안내만으로 충분하게 만드는 것입니다. Microsoft가 추가한 리디렉터 덕분에 이 안내를 따르면 적어도 무언가 유용한 일이 일어나며, PyManager를 사용하면 그 “유용한 일”이 사용자가 최신 버전을 실행하는 것이 되도록 보장할 수 있습니다.
실제로 무슨 일이 일어나는지 설명하기 위해 다음을 소개 글로 제안합니다:
Python installs on Windows are managed using an installer tool. After it has
been installed, you can run ``python`` to launch the interpreter, and it will
choose the best version already installed, available online, or referenced by
the script you are launching (if any). If you have a preference for a
particular version, you can specify it with ``py -V:<version>`` followed
by the rest of your command.
To install a version of Python without running any command, use ``py install
<version>``. You can see all of your installs with ``py list`` and remove them
with ``py uninstall <version>``. Run ``py help`` to see all the options that
are available.
Because each version of Python will be shared by all your projects, we
recommend using virtual environments. This will usually be created for a
particular Python version by running ``py -V:<version> -m venv .venv``, and
activated with ``.venv\Scripts\Activate``. Now, rather than the install
manager, ``python`` or ``py`` will always launch your virtual environment, and
any packages you install are only available while this environment is active.
To get access to the manager again, you can ``deactivate`` the environment, or
use ``py <command>``.
많은 Python 프로젝트는 자체 README 파일에 프로젝트를 실행하는 방법에 대한 정보를 포함합니다. 지금까지 이러한 정보는 사용자가 선택할 수 있는 옵션이 다양하여 복잡했습니다. 설치 관리자가 배포된 이후에는 이러한 안내를 다음과 같은 방식으로 작성할 수 있도록 제안합니다:
To install and use our application, first install Python following the
guidance for your operating system at https://docs.python.org/using/. Then,
create a virtual environment and use 'pip' to install.
``python3 -m venv .venv``
``source .venv/bin/activate`` or ``.venv\Scripts\Activate`` (on Windows)
``python -m pip install OurAwesomePackage``
...
안내에 가상 환경에 대한 정보를 포함하지 않는다면 python 또는 python3 명령을 제시할 수 있으며, Windows에서 설치 관리자를 사용하는 사용자에게는 두 명령 모두 의도한 대로 동작합니다.
현재 Windows용으로 py를 언급하는 안내는 계속 그렇게 해도 되는데, 설치 관리자가 사실상 동등한 명령을 제공하기 때문입니다. 올바른 버전을 설치하기 위해 -V: 또는 --install 옵션을 사용하는 등 Windows 전용 안내를 제공하려는 프로젝트는 설치 관리자가 설치되어 있는지 확인하기 위한 안내로 문서에 대한 링크도 함께 제공해야 합니다.
제거
완전한 제거는 사용자가 설치 관리자 제거를 고려하기 전에 다루어야 할 중요한 주제입니다. 관리자를 제거할 때 설치된 모든 부분을 자동으로 정리할 수는 없으므로, 대부분은 제거하지 않기로 했습니다. 따라서 기본 python 및 py 명령은 사라지지만, 설치된 모든 런타임은 그대로 남아 있으며 계속 사용할 수 있습니다.
다음과 같은 설명을 제안합니다:
Before you uninstall the Python install manager, you'll want to uninstall any
runtimes that you added. This can be done easily with the "purge" option:
``py uninstall --purge``
This will remove all installs and any shortcuts that would otherwise be left
behind. If you already removed the manager, you can reinstall it and run the
above uninstall command again to clean up. Individual runtimes can be
uninstalled by specifying the tag instead of ``--purge``. Tags can be found
by looking at ``python list``.
구성
설정 파일은 문서화될 일반적인 기능이지만, 일반 사용자에게 가르칠 필요는 없습니다. 마찬가지로, 시스템 관리자나 사용자가 선호하는 색인을 사용하기를 원하는 조직이 사용할 만한 고급 배포 옵션은 참조 자료에서 다루는 것이 가장 좋습니다.
사용자 지정 색인
색인은 사용자에게 특수한 런타임이나 배포판을 설치하도록 안내할 때만 소개하면 된다고 제안합니다. 색인을 제공하려는 관리자는 문서에서 관련 정보를 적극적으로 찾아볼 것으로 예상됩니다.
대체 색인을 언제, 어떻게 사용하는지 설명하기 위해 다음과 같은 취지의 문구를 제안합니다:
Our distribution can be installed on Windows using the Python Install Manager
(include link) by referencing our index:
``py install --source <your index URL here> latest``
This index contains all our versions. Use ``py list --source <URL>`` to
see everything that is available.
참조 구현
참조 구현은 작성자의 저장소에서 이용할 수 있으며, 미리 컴파일된 MSIX 패키지는 Releases 아래에 있습니다. 이 샘플에는 호스팅된 색인 대신 번들로 포함된 색인이 들어 있으며, 설치 테스트를 할 수 있도록 기존의 여러 NuGet 패키지를 참조합니다.
참조 문서도 같은 저장소에서 찾을 수 있습니다.
기각된 아이디어
모든 플랫폼에서 PyManager를 사용할 수 있도록 하기
이 아이디어에 본질적으로 반대하는 것은 아니지만, 이것이 가능해지려면 훨씬 더 많은 구성 요소가 먼저 갖추어져야 합니다.
첫째, 현재 상태로는 참조 구현에 Windows 특유의 지식이 많이 들어 있습니다. 다른 플랫폼에 대해서도 이에 상응하는 지식을 수집하고 구현해야 하며, Windows가 아닌 플랫폼에 특화된 추가 동작도 구현해야 합니다.
둘째, 시스템에 풀어 놓을 수 있는, 미리 빌드되고 재배치 가능한 바이너리의 출처가 필요합니다. 그러한 출처가 존재하기는 하지만, 공급망에서 우리가 차지하는 위치 때문에 이를 사용하는 것은 정당화될 수 없습니다(오히려 그쪽이 우리를 사용해야 합니다). Windows의 경우 우리 자체 바이너리가 이미 이러한 기준을 충족하므로, 수정 없이 다시 패키징할 수 있습니다.
셋째, 현재 구현은 번들로 포함된 Python 런타임에 의존하는데, 이 런타임은 명백한 이유로 사용자의 어떠한 간섭으로부터도 격리되어야 합니다. 이 역시 앞서 언급한 재배치 가능한 바이너리를 필요로 하는데, 현재 우리는 이를 Windows용으로만 가지고 있습니다.
다른 플랫폼에서 이를 동작하게 하려면 추가 단계가 필요하고, 해당 플랫폼의 기존 설치 프로그램을 대체할 필요도 없으므로, 이 아이디어는 이 PEP의 범위를 벗어나는 것으로 간주합니다. 향후에 추진될 수도 있습니다(그리고 이를 추진할 가능성이 가장 높은 기여자들은 이를 검토하고 있으며 일관된 인터페이스를 사용할 수 있을 것이라고 밝혔습니다).
관리자에 미리 설치된 런타임 포함하기
이 제안은 PyManager에 완전한 Python 런타임을 포함하여, python.exe 별칭이 사용 가능한 최상의 버전을 동적으로 결정하는 대신 해당 런타임을 직접 가리키도록 하자는 것입니다.
안정성과 업데이트를 위해서는 런타임 릴리스가 관리자와 완전히 독립적이어야 한다는 점이 매우 중요합니다. 기존 런타임 설치에 영향을 주지 않고 관리자를 업데이트할 수 있어야 하며, 마찬가지로 더 새로운 런타임을 얻기 위해 관리자를 업데이트해야 할 필요가 없어야 합니다.
가정해서, 설치할 필요가 없도록 Python 3.14.0을 관리자에 포함한다면 나중에 이를 3.15.0으로 교체하는 것은 호환성을 깨뜨리는 변경이 됩니다. 관리자는 설치본이 하나뿐이므로, 결과적으로 가장 최근에 설치한 사용자가 가장 오래된 런타임을 받게 됩니다.
이 방식은 또한 PyManager의 python 별칭이 버전을 지정하지 않은 별칭이라는 점도 무시합니다. 사용자가 이 별칭을 실행하는 것은 버전을 지정할 만큼 어떤 버전이 실행되는지 신경 쓰지 않았기 때문입니다. 그러한 상황에서는 사용 가능한 최선의 버전을 선택하고, (셔뱅을 통해서든 활성화된 환경을 통해서든) 적절하게 이를 고정할 수 있는 선택지를 사용자에게 제공해야 합니다.
관리자 대신 런타임을 포함하기
이것은 현재의 상황이며, 우리가 바꾸려고 하는 것입니다. 여기까지 읽고도 여전히 이 인자를 내세우기로 했다면, 처음으로 돌아가 다시 읽으십시오.
하위 명령 대신 내장 모듈 사용하기
py list나 py install 같은 명령을 사용하는 대신 제안된 두 가지 대안은 py -m list와 py -m install처럼 호출하는 전용 모듈들을 사용하거나, py -m manage list처럼 호출하는 단일 전용 모듈을 사용하는 것입니다. 이 아이디어는 기존 의미 체계로는 안정적으로 구현할 수 없는 시나리오에 그 의미 체계를 재사용하려 하므로, 설명하고 이해하고 유지 관리하기 더 어려운 특수한 경우가 필요하다는 이유로 기각됩니다.
이 아이디어가 기각되는 주된 이유는 각각으로는 바람직한 두 가지 의미 체계가 서로 충돌하기 때문입니다. 첫째, 기본 py 명령은 사용 가능한 최신 런타임을 직접 실행한 것처럼 실행해야 합니다. 둘째, -m의 동작은 일부 상황에서 특수한 경우로 취급되어서는 안 됩니다. 첫 번째 부분을 포기한다면 사용자가 기대하는 대로 동작하도록 명령을 자유롭게 수정할 수 있을 것입니다. 호환성을 완전히 깨는 데 합의한다면 누구도 호환성 문제를 제기하지 않을 것입니다. 그러나 두 번째 제약을 없앤다면, 뒤따르는 혼란의 부담은 사용자가 지게 됩니다. (우리는 둘 중 어느 것도 없애자고 제안하는 것이 아닙니다. 어쨌든 이것은 거부된 아이디어입니다. 다만 어떤 선택지가 있는지 보여 주는 데 도움이 됩니다.)
첫째, 하위 명령 중 하나는 첫 번째 런타임을 설치하기 위한 것이므로 python -m [manage] install을 기본 런타임을 통해 실행되는 것처럼 취급할 수 없습니다. 기본 런타임이 없기 때문입니다! 명령을 읽고 다른 프로그램을 통해 실행하려면 본질적으로 특수한 경우의 처리가 필요합니다.
게다가 Python에서는 다른 옵션이 -m 앞에 오거나 -m과 섞여 올 수 있으며, 이 특수한 경우는 그런 사용법까지 지원해야 합니다.
마지막으로, -m 옵션의 의미 체계에는 초기 sys.path에서 일치하는 모듈 이름을 검색하는 동작이 포함됩니다. 이는 단순한 이름보다 훨씬 넓은 범위의 검색입니다. py -m install은 파일 시스템, 환경, 레지스트리를 조사하여 찾은 여러 디렉터리와 그 안에서 전이적으로 포함된 모든 경로를 검색한 후 install.py, install.pyc, install.pyd, install\\__init__.py 등을 기꺼이 실행할 것입니다. 현재 작업 디렉터리에서 정확히 install이라는 이름의 파일만 찾는 py install과 비교하면, -m의 동작은 실제 시나리오에서 이미 의존하고 있을 가능성이 훨씬 큽니다. (예를 들어 Django 프로젝트에는 보통 manage.py 스크립트가 있으므로 py -m manage는 항상 잘못 동작하게 됩니다.)
py -m install이 -m처럼 동작하지 않고 대신 내부 명령을 실행하도록 바꾸는 것은 py install을 바꾸는 것보다 사용자 환경을 깨뜨릴 가능성이 훨씬 큽니다. 따라서 이 아이디어는 기각합니다.
하위 명령 대신 새로운 명령줄 옵션 사용하기
하위 명령에 대한 합리적인 대안은 하위 명령이 아니라 옵션처럼 이름 앞에 구두점을 붙여 지정하는 것입니다. 예를 들어 py install 대신 py /install ...이나 py --list와 같은 형태가 될 수 있습니다. 이들 중 일부는 현재 일반 CPython 인터프리터에서 오류이므로, 하위 호환성 걱정 없이 추가할 수 있습니다.
그러나 주목할 점은, 앞에 슬래시를 붙이는 일반적인 Windows 형식은 CPython에서 오류가 아니라는 것입니다. 따라서 Windows 사용자는 기존 지식을 그대로 적용할 수 없으며, 옵션을 지정하는 새로운 방법을 배워야 합니다. 우리가 제안하는 것은 Windows 전용 도구이므로, 이는 매우 나쁜 출발입니다. 또한 Unix 스타일 명령줄에 익숙한 사용자는 옵션을 명령으로 오용하고 있다는 것을 알아차릴 것입니다.
우리는 깔끔한 인터페이스를 만들고자 하며, 명백한 결점이나 학습상의 어려움을 포함한 설계로 시작하는 것은 그 목표에 어긋납니다. 현대의 도구들은 이러한 목적에 보편적으로 하위 명령을 사용하므로, 다른 방식을 사용하자는 아이디어는 기각됩니다.
대신 현재의 기존 설치 프로그램 개선하기
새로운 설치 메커니즘을 만드는 대신, 현재 설치 프로그램을 유지 관리하는 데 투자할 수도 있습니다. 그러나 현 시점에서 현재 설치 프로그램은 전적으로 지원이 종료된 기술을 기반으로 합니다. Windows는 더 이상 Windows 설치 프로그램(Windows Installer) 서비스를 개발하지 않으며, Wix도 우리가 사용하는 버전의 도구 모음을 더 이상 개선하지 않습니다. 더 새로운 Wix Toolset으로 이전하려면 상당한 작업이 필요하며, 결국에는 여전히 오래된 기술에 묶여 있게 됩니다.
앞서 언급했듯이, Windows 설치 프로그램(Windows Installer)이 제공하는 가장 유익한 기능은 CPython에서 사용되지 않으며, 대체로 해결한 문제보다 더 많은 문제를 일으켜 왔습니다(예를 들어, 자동으로 수집된 파일 버전 정보로 인한 의도치 않은 다운그레이드).
설치 프로그램 로직의 주된 원천인 Burn 번들의 구현은 C++로 작성되어 있으며, 이를 잘 아는 코어 개발자가 거의 없는 프레임워크에 통합되어 있습니다. 이 때문에 유지 관리가 어려우며, 장기적으로 취하기에 좋은 방향이 아닙니다. 등록 없는 설치와 같은 원하는 기능을 Burn 번들로 이전하는 것은 (처음부터 끝까지 다시 구현한 뒤 이를 나중에 덧붙이듯 통합하지 않는 한) 불가능합니다.
현재의 전통적인 설치 프로그램을 유지 관리하는 데는 최소한 새로운 설치 프로그램을 구현하는 것만큼의 노력이 들며, 코어 팀이나 사용자에게 의미 있는 이점을 제공하지 못할 것이라는 것이 우리의 견해입니다. 따라서 이 아이디어는 기각합니다.
스토어 패키지를 완전히 삭제하기
스토어 패키지를 제거하면 사용자가 Python 런타임을 선택할 때 마주하는 선택지의 수가 줄어들 것입니다. 신뢰성과 보안을 제외한 모든 척도에서 전통적인 설치 프로그램은 대체 수단으로서 전적으로 충분합니다. 생태계의 일부를 더 안전한 설정(예: DLL 하이재킹에 의존하지 않는 것)으로 이전하려는 노력은 대부분 이루어졌지만, 여전히 덜 안전한 구성에서만 동작하는 일부 패키지가 남아 있으며, 모든 사용자를 이러한 구성으로 되돌리면 이러한 패키지의 사용자들이 현재 겪는 문제를 더 이상 겪지 않게 될 것입니다.
그러나 스토어 패키지 사용자의 대다수는 불만이 없는 것으로 보입니다. 일화적으로 보면, 이들은 스토어 설치에 대체로 매우 만족하며 특히 설치의 간편함과 신뢰성을 높이 평가합니다. (그리고 개인적인 이야기를 덧붙이자면, 이 글의 저자는 Python 3.8 이후로 스토어 패키지만을 사용해 왔으며 작업을 가로막는 문제를 겪은 적이 없습니다.)
가장 많은 문제는 잘못 구성된 PATH 변수와 Microsoft가 설치한 기본 python.exe 리디렉터로 인해 발생했습니다. 다시 말해, 우리 패키지와는 전혀 관계가 없습니다(다만 때로는 우리의 다른 설치 프로그램에 있는 해결할 수 없는 문제와 관련되기도 합니다). 이 경로를 통한 성공적인 설치가 많다는 점을 고려하여, 우리는 영향을 받은 사용자의 문제를 진단하고 지원하는 부담을 감수할 가치가 있다고 판단하며, 스토어 패키지를 단순히 없애자는 아이디어는 기각합니다.
다만 PyManager가 스토어에 게시되면, 사용자가 관리자를 찾을 수 있도록 스토어에 있는 기존 런타임을 모두 목록에서 내릴 계획입니다. 이는 새로운 설치에만 영향을 미치며, 이전에 특정 버전을 설치한 적이 있는 사람은 누구나 (로그인되어 있었다면 다른 컴퓨터에서 설치했더라도) 해당 버전을 계속 사용하고 설치할 수 있습니다.
WinGet 또는 그에 상응하는 도구에 의존하기
WinGet, Chocolatey 및 기타 유사한 도구는 우리가 요구하는 의미에서의 설치 프로그램이 아닙니다. 이러한 도구는 자체 메타데이터 저장소를 사용하여 설치 프로그램을 다운로드하고, 검증하고, 실행합니다. 우리 자체의 설치 프로그램이 없으면 이러한 도구는 실행할 것이 없으므로 사용할 수 없습니다.
이러한 도구의 메타데이터가 PyManager를 설치한 다음 이를 실행하여 특정 런타임을 설치하는 방식을 지원하지 않을 가능성도 있습니다. 그런 경우라면 이러한 도구는 우리의 바이너리 패키지를 직접 사용하는 방안을 검토해야 할 수도 있습니다.
현재 이러한 설치 도구 중 어느 것도 CPython이 공식적으로 지원하지 않으므로, 우리에게는 이들이 동작하도록 만들 의무가 없습니다.
모든 버전을 Windows 스토어 패키지로 만들기
현재 하는 것처럼 각 버전을 Windows 스토어에 릴리스하되, 목록에 표시되지 않게 하고 설치 프로그램(PyManager, WinGet 또는 스토어 패키지를 설치할 수 있는 다른 도구가 될 수 있습니다)에 의존하는 것도 가능합니다. 이렇게 하면 사용자를 혼란스럽게 할 위험을 피하면서, 패키지 관리에 대한 우리 자신의 책임을 크게 단순화할 수 있습니다.
패키지 업데이트는 수작업이므로, 이 방식은 Store 게시 인터페이스에 접근할 수 있는 기여자에게 누구든 상당한 부담을 지우게 됩니다. 또한 모든 Python 런타임에 앞서 설명한 기술적 제약이 그대로 남게 됩니다. 따라서 이 아이디어는 기각합니다.
모든 버전을 ZIP이 아닌 MSIX 패키지로 만들면 Store 게시 인터페이스를 거치지 않아도 되지만, 여전히 사용자에게 기술적 제약을 부과하게 됩니다. 이 방안 역시 기각합니다.
일반 ZIP 파일만 게시하기
일반 ZIP 파일을 게시하는 것은 계획에 포함되어 있지만, 눈에 띄게 목록에 올리지는 않습니다(예를 들어 python.org 다운로드 페이지에는 표시되지 않지만, FTP 보기에서는 볼 수 있습니다). 대안으로는 이 패키지들을 게시하고 목록에 올린 다음, 사용자가 직접 내려받아 수동으로 압축을 풀고 구성하도록 하는 방법이 있습니다.
우리가 보는 워크플로를 고려할 때, 대부분의 사용자는 Python 설치를 전혀 설정하고 싶어 하지 않는다고 판단합니다. 사용자는 설치 위치를 고르고 싶어 하지 않을 뿐 아니라 버전을 고르고 싶어 하지도 않으며, 다운로드 제공처나 설치 안내를 찾아다니는 것조차 원하지 않습니다. 하지만 나중에 설치된 Python을 찾고, 실행하고, 업데이트하거나 제거하고, 알려진 모든 설치 목록을 볼 수 있기를 원합니다.
또한 현재 다운로드 페이지에 올라와 있는 것보다 더 많은 ZIP 파일이 생기므로 파일 목록이 더 길어진다는 점도 짚어 둘 만합니다. 올바른 다운로드 파일을 고르는 일은 이미 사용자(기본 “Download” 버튼을 거치지 않고 사용 가능한 모든 버전 목록과 그 파일 목록을 살펴보는 사용자)에게 어려운 일이며, 우리는 이를 더 어렵게 만들 생각이 없습니다.
색인 프로토콜과 다운로드 목록은 이를 사용하려는 도구나, URL을 찾기 위해 JSON을 탐색할 의향이 있는 사용자가 이용할 수 있습니다. 또한 install 명령의 --target 옵션은 간단한 다운로드 및 압축 해제 기능을 제공하므로, 사용자는 ZIP 파일을 쓸 때와 같은 경험을 할 수 있습니다. 그리고 --download 옵션을 사용하면 압축된 상태 그대로의 ZIP 파일을 받을 수 있습니다.
PyManager를 한 곳에만 게시하기
Windows Store든 python.org든, 한 곳에만 게시하는 것도 가능한 방안입니다.
하지만 사용자는 python.org에서 무언가를 내려받을 수 있기를 강하게 기대합니다. 어느 선택지든 하나라도 없앤다면 사용자에게 피해를 줄 수밖에 없습니다. python.org에서 MSIX를 제공하지 않으면, 사용자는 패키지를 다른 컴퓨터로 옮기거나 관리자의 초기 설치를 완전히 스크립트로 처리할 방법이 없습니다.
많은 사용자가 패키지 설치에 Windows Store 앱을 이용하며, Windows에 내장된 리디렉터는 Store 페이지만 열 수 있습니다. 따라서 Store 앱을 없애는 것은 매달 수십만 건의 설치를 막는 것과 같습니다.
두 빌드는 사실상 동일합니다. Store에 제공하는 MSIX와 python.org에 올라가는 MSIX의 유일한 차이는 패키지 서명입니다. python.org 패키지는 우리가 직접 서명하고, Store 패키지는 게시 과정에서 서명됩니다. 그 외에는 두 패키지를 모두 만들고 게시하는 데 추가 비용이 들지 않습니다.
인라인 스크립트 메타데이터
PEP 723은 인라인 스크립트 메타데이터를 도입했습니다. 이는 서드파티 도구가 해석한 뒤 올바른 환경에서 Python 스크립트를 실행하도록 하기 위한 구조화된 주석입니다. 해당 PEP에서 가져온 예시는 다음과 같습니다:
# /// script
# requires-python = ">=3.11"
# dependencies = [
# "requests<3",
# "rich",
# ]
# ///
PyManager는 의존성 설치를 자체적으로 지원하지 않으며, 이를 추가하자고 제안하지도 않습니다. 그 결과 이 메타데이터 처리를 완전히 구현할 수 없었으며, 부분적인 처리는 아예 처리하지 않는 것보다 못하다고 보기 때문에 전혀 구현하지 않기로 합니다.
사용자는 제약 조건을 옵션으로 직접 지정할 수 있습니다. 예를 들어 py -V:>=3.11 my-script.py와 같이 지정하면 같은 선택 동작을 얻을 수 있습니다.
메타데이터를 감지하여 선택된 런타임이 해당 요구 사항과 맞지 않을 때 경고할 수도 있지만, 이는 초기 제안에 포함되지 않습니다.
Copyright
This document is placed in the public domain or under the CC0-1.0-Universal license, whichever is more permissive.