PEP 704 – 패키지 설치 프로그램에서 기본적으로 가상 환경 요구하기

Author:

Pradyun Gedam <pradyunsg at gmail.com>

Sponsor:

Brett Cannon <brett at python.org>

PEP-Delegate:

Paul Moore <p.f.moore at gmail.com>

Discussions-To:

Discourse thread

Status:

Withdrawn

Type:

Standards Track

Topic:

Packaging

Created:

16-Jan-2023

Post-History:

16-Jan-2023

---

Table of Contents

• 초록
• PEP 철회
• 동기
• 근거
• 명세
  • 기본적으로 가상 환경 요구하기
  • 가상 환경 사용 거부하기
  • 변경 사항에 대한 일관된 일정
• 하위 호환성
• 보안 영향
• 교육 방법
• 참조 구현
• 구현 참고 사항
  • 활성화된 가상 환경 감지하기
  • 가상 환경 사용에 관한 문서
• 기각된 아이디어
  • 가상 환경 디렉터리의 이름을 지정하지 않기
  • 가상 환경 디렉터리에 다른 이름 사용하기
  • 도구의 동작을 Python 버전과 결합하지 않기
• 미해결 문제
• Copyright

번역·라이선스 안내

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

초록

이 PEP는 pip 같은 패키지 설치 프로그램이 Python 3.13 이상에서 기본적으로 가상 환경을 요구하도록 권장합니다.

PEP 철회

이 PEP를 논의하는 과정에서, 제안된 것과 달리 pip의 UX 변경은 PEP로 결정되는 사항이 아니라는 점이 분명해졌습니다. 또한 상당수의 사용자가 pip가 관리하는 의존성과 다른 도구가 관리하는 의존성을 섞어 쓸 수 있다는 점에 의존하고 있다는 사실도 분명해졌습니다(가장 대표적인 경우는 Conda를 사용할 때입니다).

더 나아가, 제안된 변경이 주는 이점 중 상당 부분은 PEP 668을 통해 얻을 수 있습니다(이 글을 쓰는 시점에 이미 수락되어 구현되었습니다). 이를 통해 Python 인터프리터 재배포자는 사용자에게 가상 환경 사용을 요구할지, 사용자에게 어떤 메시지를 보여 줄지, 그리고 그 변경을 자신의 사용자에게 어떻게 단계적으로 적용할지를 제어할 수 있습니다.

pip으로 가상 환경 사용을 강제하는 것이 이 PEP의 주된 초점이었으므로, 이 PEP를 다른 주제로 재정비하기보다는 철회하는 것이 더 적절하다고 판단했습니다.

가상 환경 이름 규칙에 관한 질문과 문제를 해결하기 위한 향후 PEP는 여전히 적절하겠지만, 그러한 노력은 규칙의 강제보다는 그 규칙의 이점에 초점을 맞춘 새로운 PEP로 시작하는 것이 좋습니다.

동기

Python 가상 환경은 Python 개발 워크플로의 필수적인 부분입니다. 하지만 가상 환경은 선택적으로 사용하는 기능이기 때문에 추가적인 노력이 필요하며, 사용자에게 다음 중 하나를 요구합니다:

• 가상 환경을 활성화/비활성화하기 위한 명시적인 절차 수행
• 파일을 실행할 때 <path-to-venv>/<bin-path>/<executable> 사용

새로운 사용자에게는 가상 환경을 사용하지 않아도 모든 것이 겉보기에는 제대로 동작하는 것처럼 보입니다 -— 동작하지 않게 되기 전까지는 말입니다. 게다가 가상 환경을 활성화하는 문법과 메커니즘은 플랫폼마다 조금씩 다릅니다. 이 때문에 가상 환경을 소개하기가 복잡해집니다. 워크플로에 추가 단계를 더하는 것을 정당화하려면, 가상 환경이 어떻게, 왜 유용한지에 대한 정보와 맥락을 이제 설명해야 하기 때문입니다.

또한 사용자가 pip 같은 설치 프로그램을 실행하기 전에 가상 환경을 활성화하거나 해당 설치 프로그램이 오류를 내도록 설정하는 것을 기억해야 하므로 실수가 생길 여지가 있습니다. 일부 Linux 배포판에서는 이를 잊으면 설치 프로그램이 운영 체제 소유의 파일을 수정하게 될 수 있습니다(환경을 그에 맞게 표시하기로 옵트인한 배포판에서는 PEP 668에 의해 이 문제가 부분적으로 완화됩니다).

근거

pip 같은 설치 프로그램의 기본 동작을 가상 환경이 활성화되어 있어야 하도록 변경하면 다음과 같은 효과가 있습니다:

• 새로운 사용자가 Python을 더 쉽게 시작할 수 있게 됩니다(일관된 경험을 제공하고, 가상 환경을 반드시 사용해야 하는 것으로 이해하게 되기 때문입니다)
• 기본적으로 모든 사용자에게서 의도치 않은 설치 문제가 생길 여지를 줄입니다(가상 환경을 사용하고 있지 않을 때 이를 명시적으로 알려 주기 때문입니다).

가상 환경을 프로젝트 트리 내부의 .venv라는 디렉터리에 두는 규칙을 정하면, 일반적인 워크플로에서 결정해야 할 사항이 하나 줄어들고 생태계 안에 명확한 규칙이 생깁니다.

명세

기본적으로 가상 환경 요구하기

사용자가 활성화된 가상 환경 없이 설치 프로그램을 실행하면, 설치 프로그램은 오류 메시지를 출력하고 0이 아닌 종료 코드로 종료해야 합니다(SHOULD).

오류 메시지는 사용자에게 가상 환경이 필요하다는 것을 알려야 하고(SHOULD), .venv라는 이름의 가상 환경을 만들고 활성화하는 방법에 대한 셸별 안내를 제공해야 하며(SHOULD), 가상 환경을 만들고 활성화하는 방법을 설명하는 문서 페이지 링크를 제공해야 합니다(SHOULD).

자세한 내용은 Implementation Notes를 참고하십시오.

가상 환경 사용 거부하기

설치 프로그램은 또한 이 요구 사항을 비활성화하는 명시적인 옵트인 수단을 제공하여 최종 사용자가 가상 환경 밖에서도 설치 프로그램을 사용할 수 있도록 해야 합니다(SHOULD). 설치 프로그램이 이 기능을 제공하지 않는다면, 오류 메시지와 문서 페이지에 그 사실을 언급해야 합니다(SHOULD).

변경 사항에 대한 일관된 일정

설치 프로그램은 어떤 Python 버전에서든 이 기본 동작을 구현하기로 선택할 수 있지만(MAY), Python 3.13 이상에서는 구현해야 합니다(SHOULD).

하위 호환성

이 PEP는 사용자가 가상 환경 밖에서 설치 프로그램을 사용하는 워크플로와 하위 호환되지 않습니다. 이러한 사용자에게는 오류 메시지가 표시되며, 사용자는 다음 중 하나를 해야 합니다:

• 가상 환경 밖에서 설치 프로그램을 실행하도록 명시적으로 옵트인하거나,
• 가상 환경을 만들어 사용합니다.

이미 가상 환경을 사용하고 있는 사용자는 이 변경의 영향을 받지 않습니다.

(내부적으로 사용자를 대신해 가상 환경을 관리하는) 워크플로 도구는 이미 설치 프로그램을 실행할 때 가상 환경을 사용하고 있을 것이므로 영향을 받지 않을 것입니다.

보안 영향

이 PEP는 새로운 보안 영향을 도입하지 않습니다.

교육 방법

이 PEP는 새로운 사용자가 Python 패키지를 사용하기 시작하려면 가상 환경을 만들어 사용하도록 요구합니다. 하지만 이는 모범 사례입니다. Python 패키징 사용자 가이드(Python Packaging User Guide)의 “Python 패키지 설치 방법의 기초” 섹션이 보여주듯이 말입니다. 이 섹션은 pip 사용을 다루기 전에 가상 환경이 무엇인지, 어떻게 동작하는지를 먼저 설명합니다.

참조 구현

이 PEP에는 참조 구현이 없습니다. 하지만 제안된 동작은 이미 대부분 pip에 구현되어 있으며, PIP_REQUIRE_VENV 환경 변수를 1로 설정하여 활성화할 수 있습니다. (설정하지 않으면 설치에 가상 환경을 요구하지 않는, 제안된 옵트인 동작이 적용됩니다.)

구현 참고 사항

활성화된 가상 환경 감지하기

PEP 668에서 논의한 것처럼, 가상 환경을 견고하게 감지하는 로직은 대략 다음과 같습니다:

def is_virtual_environment():
    return sys.base_prefix != sys.prefix or hasattr(sys, "real_prefix")

가상 환경 사용에 관한 문서

패키지 설치 프로그램은 오류 메시지에 문서 페이지 링크를 제공해야 합니다.

이상적으로는 이러한 문서 페이지에서 가상 환경이 무엇인지, 왜 필요한지, 그리고 venv를 사용하여 가상 환경을 만들고 활성화하는 방법을 설명해야 합니다. 또한 가장 일반적인 셸과 플랫폼에 대한 안내를 포함해야 합니다.

이 주제를 다루기 위해 설치 프로그램마다 중복으로 들이는 노력을 줄이도록, 그러한 문서 페이지는 Python Packaging User Guide에 마련되어야 합니다.

기각된 아이디어

가상 환경 디렉터리의 이름을 지정하지 않기

가상 환경 디렉터리에 일관된 이름을 사용하는 것은 몇 가지 이유로 중요합니다:

1. 사용자가 가상 환경 디렉터리를 찾고 활성화하기가 더 쉬워집니다.
2. 새로운 사용자가 가상 환경 디렉터리의 이름을 정할 필요가 없으므로, 결정해야 할 사항이 하나 줄어듭니다.
3. 생태계 내에 명확한 관례가 생기므로 사용자가 문서를 더 쉽게 찾을 수 있습니다.
4. 여러 도구 간의 일관성이 보장되므로 오류 메시지의 차이 때문에 사용자가 혼란을 겪지 않습니다.

가상 환경 디렉터리에 다른 이름 사용하기

일관된 권장 사항이 하나만 있다면 기능적으로 디렉터리 이름은 크게 중요하지 않습니다.

.venv라는 이름을 선택한 이유는 다음과 같습니다.

1. 유효한 Python 임포트 이름과 충돌하지 않습니다.
2. 표준 라이브러리의 venv 모듈과 충돌하지 않습니다.
3. Python 커뮤니티에서 이미 사용되어 왔습니다.
4. 일반적인 텍스트 편집기에서 자동 감지를 지원합니다.
5. 일반적인 키보드 배열에서 보조 키 없이 입력할 수 있습니다.

도구의 동작을 Python 버전과 결합하지 않기

이 PEP는 설치 프로그램의 동작과 Python 버전 사이에 결합을 만듭니다.

이는 설치 도구의 동작 변경에 이미 사용되고 있는 도입 방식입니다. 예를 들어, Python 3.11의 pip은 패키지 메타데이터를 파싱하거나 가져올 때 pkg_resources 대신 importlib.metadata를 사용하고, 휠을 풀 경로를 얻을 때 distutils.sysconfig 대신 sysconfig를 사용합니다.

이러한 사례와의 차이점은 그 변경들이 최종 사용자에게 대체로 드러나지 않도록 되어 있다는 것입니다. 이 PEP는 최종 사용자에게 드러나며 사용자의 조치가 필요한 동작 변경을 제안합니다.

이 방식의 주된 이점은 재배포자가 새 Python 버전에 맞춰 제때 도구를 조정할 수 있게 하고, 생태계 전반에 걸쳐 명확하고 일관된 변경 시점을 제공한다는 것입니다. 또한 기본 동작이 언제부터 일관되게 가상 환경을 기본으로 요구하게 되는지(Python 3.12의 지원이 종료되는 시점)에 대한 명확한 기한을 정해 줍니다.

이 접근 방식의 주된 문제는 사용자가 새 Python 버전으로 업그레이드할 때 동작 변경을 강제하므로 새 Python 버전의 도입을 방해할 수 있다는 것입니다. 그러나 이는 기존 사용자에게는 마이그레이션/업그레이드이며, 마이그레이션/업그레이드에는 어느 정도의 변경이 필요하다는 것이 일반적인 예상입니다.

이 PEP의 작성자는 기한을 두고 생태계 전반에 일관되게 적용하는 이점이 업그레이드 시 사용자에게 모범 사례를 강제하는 단점보다 크다고 믿습니다.

미해결 문제

없습니다.

Copyright

This document is placed in the public domain or under the CC0-1.0-Universal license, whichever is more permissive.