PEP 394 – 유닉스 계열 시스템의 “python” 명령
- Author:
- Kerrick Staley <mail at kerrickstaley.com>, Alyssa Coghlan <ncoghlan at gmail.com>, Barry Warsaw <barry at python.org>, Petr Viktorin <encukou at gmail.com>, Miro Hrončok <miro at hroncok.cz>, Carol Willing <willingc at gmail.com>
- Status:
- Active
- Type:
- Informational
- Created:
- 02-Mar-2011
- Post-History:
- 04-Mar-2011, 20-Jul-2011, 16-Feb-2012, 30-Sep-2014, 28-Apr-2018, 26-Jun-2019
- Resolution:
- Python-Dev message
번역·라이선스 안내
이 비공식 한국어 번역은 원문 Copyright 절의 Public Domain 조건에 따라 제공합니다. 원저자와 공식 원문은 그대로 표시합니다. 수정되지 않은 기준 원문 · 공식 최신판
초록
이 PEP는 python명령이 호출될 때 Python 스크립트의 동작을 개요로 설명합니다. 배포판 또는 시스템 구성에 따라 python이 설치될 수도 있고 설치되지 않을 수도 있습니다. python이 설치된 경우 해당 대상 인터프리터는 python2또는 python3을 참조할 수 있습니다. 최종 사용자는 유닉스 계열 시스템 간에 이러한 불일치가 있다는 사실을 알지 못할 수 있습니다. 이 PEP의 목표는 python이 무엇을 참조하는지와 스크립트가 어떻게 동작할지에 대한 사용자의 혼란을 줄이는 것입니다.
이 PEP의 다음 절에 나오는 권고 사항에서는 다음과 같은 경우의 동작을 설명합니다:
- 가상 환경 사용
python2또는python3용 셰뱅을 사용하는 크로스 플랫폼 스크립트 작성
이 PEP의 목표는 스크립트 최종 사용자, 배포 제공자 및 스크립트 유지 관리자/작성자를 위해 동작을 명확히 하는 것입니다.
권고 사항
권고 사항은 다음과 같이 자세히 설명합니다. 이러한 권고 사항의 근거가 되는 예상 사항도 명시합니다.
Python 런타임 배포자를 위한 권고 사항
- 유닉스 계열 소프트웨어 배포판(macOS 및 Cygwin과 같은 시스템 포함)은 Python 2 인터프리터의 한 버전이 설치될 때마다
python2명령을 기본 경로에 설치하고,python3및 Python 3 인터프리터에 대해서도 동일하게 설치할 것으로 예상합니다. - 호출되면
python2는 Python 2 인터프리터의 어떤 버전을 실행하고,python3는 Python 3 인터프리터의 어떤 버전을 실행해야 합니다. python명령이 설치된 경우python3명령과 동일한 Python 버전 또는python2명령과 동일한 Python 버전을 호출할 것으로 예상합니다.- 배포자는
python명령의 동작을 다음과 같이 설정할 수 있습니다:python2,python3,python명령을 제공하지 않고, 최종 사용자나 시스템 관리자가python을 구성할 수 있도록 합니다.
- Python 3.x의
idle,pydoc및python-config명령은 마찬가지로idle3,pydoc3및python3-config로 제공되어야 하며, Python 2.x 버전은idle2,pydoc2및python2-config로 제공되어야 합니다. 버전 번호가 없는 명령은python명령과 동일한 Python 버전을 호출하거나, 아예 제공되지 않아야 합니다. - 서드파티 Python 스크립트를 패키징할 때 배포자는 덜 구체적인 셰뱅을 더 구체적인 셰뱅으로 변경하는 것이 권장됩니다. 이렇게 하면 사용 가능한 최신 버전의 Python으로 소프트웨어를 사용하게 되며, Python 2에 대한 종속성을 제거할 수도 있습니다. 어떤 세부 사항을 설정할지는 배포자에게 맡깁니다. 세부 사항의 예는 다음과 같습니다:
- Python 3.x가 지원되는 경우
python셰뱅을python3로 변경합니다. - Python 3.x가 아직 지원되지 않는 경우
python셰뱅을python2로 변경합니다. - 소프트웨어가 Python 3.8로 빌드된 경우
python3셰뱅을python3.8로 변경합니다.
- Python 3.x가 지원되는 경우
- 가상 환경(PEP 405
venv패키지 또는virtualenv나conda와 같은 유사한 도구로 생성됨)이 활성화된 경우,python명령은 가상 환경의 인터프리터를 가리켜야 하며 항상 사용할 수 있어야 합니다.python3또는python2명령도 환경의 인터프리터 버전에 따라 사용할 수 있어야 합니다.
파이썬 스크립트 게시자
- 파이썬 스크립트에서 인터프리터를 다시 호출할 때는 인터프리터 위치에 관한 하드코딩된 가정을 피하기 위해
sys.executable을 조회하는 방식이 여전히 권장되는 접근법입니다. - 최종 사용자가 가상 환경을 사용하도록 권장하십시오. 이렇게 하면 사용자의 환경을 더 예측 가능하게 만들고(문제가 줄어들 수 있음), 시스템을 방해하는 일을 피하는 데 도움이 됩니다.
- 활성화된 가상 환경에서만 실행될 것으로 예상되는 스크립트의 경우, 셰뱅 줄을
#!/usr/bin/env python로 작성할 수 있습니다. 이는 스크립트가 활성 가상 환경을 따르도록 지시합니다. - 스크립트가 가상 환경 외부에서 실행될 것으로 예상되는 경우, 개발자는 플랫폼과 설치 방법에 따른 다음과 같은 차이점을 알고 있어야 합니다.
- 이전 Linux 배포판은 Python 2를 가리키는
python명령을 제공하며,python2명령은 제공하지 않을 가능성이 높습니다. - 일부 최신 Linux 배포판은 Python 3을 가리키는
python명령을 제공합니다. - 일부 Linux 배포판은 기본적으로
python명령을 전혀 제공하지 않지만,python3명령은 기본적으로 제공합니다.
- 이전 Linux 배포판은 Python 2를 가리키는
- 이러한 환경을 대상으로 할 가능성이 있는 경우, 개발자는 설치된 환경에 맞게 셰뱅 줄을 다시 작성하는 Python 패키지 설치 도구를 사용하거나, 셰뱅 줄을 대화형으로 업데이트하는 방법을 안내하거나, 대상 환경에 맞게 조정된 더 구체적인 셰뱅 줄을 사용해야 합니다.
- “old systems”와 기본
python명령이 없는 시스템을 모두 대상으로 하는 스크립트는 절충안을 마련하고 이 상황을 문서화해야 합니다. 셰뱅을 사용하지 않는 것이 이 문제에 권장되는 해결 방법입니다(console_scripts Entry Points ([9]) 또는 이와 유사한 수단을 사용). - 컨테이너나 가상 환경과 같은 특정 환경 전용으로 설계된 애플리케이션은 계속해서
python명령 이름을 사용할 수 있습니다.
Python 최종 사용자
python은 모든 환경에서 사용할 수 있는 것은 아니지만, Python을 명시적으로 호출할 때 여전히 권장되는 표기입니다. 이는 가상 환경이 서로 다른 플랫폼과 Python 설치에서 일관되게 사용할 수 있도록 만드는 표기이기 때문입니다.- 시스템과 함께 배포되지 않았거나 시스템용으로 개발되지 않은 소프트웨어의 경우, 시스템의 Python 설치를 방해하지 않도록
conda나pipenv와 같은 환경 관리자를 함께 사용하여 가상 환경을 사용하는 것이 좋습니다.
이러한 권장 사항은 2011년 3월과 7월의 관련 python-dev 논의([1], [2]), 2012년 2월([4]), 2014년 9월([6]), 2018년 4월 GitHub에서의 논의([7]), 2019년 2월 python-dev에서의 논의([8]), 그리고 2019년 5월/6월 PEP 업데이트 검토([10])의 결과입니다.
이 PEP의 역사
2011년에는 대부분의 배포판이 python 명령을 Python 2에 별칭으로 연결했지만, 일부 배포판은 이를 Python 3으로 전환하기 시작했습니다([5]). 이전 배포판 중 일부는 기본적으로 python2 명령을 제공하지 않았으므로, 과거에는 Python 2 코드(또는 sys.executable을 통하지 않고 Python 2 인터프리터를 직접 호출하는 코드)가 수정 없이 모든 Unix 계열 시스템에서 안정적으로 실행될 방법이 없었습니다. 일부 시스템에서는 python 명령이 잘못된 인터프리터 버전을 호출하고, 다른 시스템에서는 python2 명령이 완전히 실패했기 때문입니다. 이 PEP는 원래 배포판 유지 관리자가 수행해야 하는 추가 작업을 최소화하면서 플랫폼 간 지원을 복원하는 매우 간단한 메커니즘을 제공했습니다. 간단히 말해, 권장 사항은 다음과 같았습니다.
python명령은 Python 2와 3 모두에 호환되는 코드에 선호되었습니다(이미 Python 3으로 별칭이 지정된 시스템에서도 모든 시스템에서 사용할 수 있었기 때문입니다).python명령은 항상 Python 2를 호출해야 했습니다(Python 2 코드가 Python 3에서 실행될 때 진단하기 어려운 오류를 방지하기 위해서입니다).- 버전을 명시적으로 지정할 수 있도록
python2및python3명령을 사용할 수 있어야 했습니다.
그러나 이러한 권장 사항은 Python 2를 항상 사용할 수 있다고 암묵적으로 가정했습니다. Python 2가 2020년에 수명 종료에 가까워짐에 따라(PEP 373, PEP 404), 배포판은 Python 2를 선택 사항으로 만들거나 완전히 제거하고 있습니다. 이는 python 명령을 제거하거나 Python 3을 호출하도록 전환하는 것을 의미합니다. 일부 배포자들은 PEP의 원래 권장 사항을 무시하는 편이 사용자에게 더 도움이 된다고 판단했으며, 시스템 관리자가 특정 환경의 필요에 따라 시스템을 구성할 수 있는 자유를 제공했습니다.
현재의 근거
2019년 기준으로, 스크립트를 실행하기 전에 Python 가상 환경(또는 이에 기능적으로 동등한 것)을 활성화하는 것은 플랫폼과 배포판에 걸쳐 일관된 경험을 얻는 한 가지 방법입니다.
따라서 배포자는 소프트웨어 사용자가 적절한 실행 환경을 제공할 것으로 예상할 수 있습니다.
이 권고에 대한 향후 변경 사항
이 권고는 향후 몇 년 동안 정기적으로 검토되며, 핵심 개발 팀이 적절하다고 판단할 때 업데이트됩니다. 참고로 Python 2.7 시리즈의 정기 유지 보수 릴리스는 2020년 1월까지 계속됩니다.
마이그레이션 참고 사항
이 절에는 핵심 CPython 개발자가 제시한 공식 권고 사항이 포함되어 있지 않습니다. 이 절은 시스템의 기본 Python 버전으로 Python 3으로 마이그레이션하는 다양한 측면에 관한 참고 사항을 모아 놓은 것에 불과합니다. 이러한 내용은 그러한 변경을 고려하는 모든 배포판에 도움이 되기를 바랍니다.
- 배포판이
python명령을python2에서python3으로 전환할 때의 주된 장벽은 배포판 내부의 손상이 아니라, 시스템 관리자와 기타 사용자가 개발한 비공개 서드파티 스크립트의 손상입니다.python명령이 기본적으로python3을 호출하도록 업데이트하는 것은, 배포판이 Python 3의 하위 호환성이 없는 변경 사항에 익숙하지 않은 사용자에게는 상당히 혼란스러울 수 있는 오류로 그러한 스크립트를 중단할 의사가 있음을 나타냅니다. 예를 들어,print를 문에서 내장 함수로 변경하는 것은 자동 변환기가 처리하기에 비교적 간단하지만, Python 3에서 Python 2 표기법을 사용하려고 할 때 발생하는 SyntaxError는 이러한 변경을 알지 못하는 사용자에게 혼란스러울 수 있습니다:$ python3 -c 'print "Hello, world!"' File "<string>", line 1 print "Hello, world!" ^ SyntaxError: Missing parentheses in call to 'print'. Did you mean print("Hello, world!")?
숙련된 Python 사용자에게는 이것이 분명할 수 있지만, 그러한 스크립트는 Python을 전혀 모르는 사람이 실행할 수도 있습니다. 그러한 서드파티 스크립트의 손상을 방지하는 것이 이 PEP에서
python이 계속python2를 가리키도록 권고했던 핵심 이유입니다. python: command not found오류 메시지는 Python을 잘 모르는 사람에게도 놀라울 정도로 해결 가능한 단서를 제공하는 경향이 있습니다.pythonX.X(예:python3.6) 명령은 최신 시스템에 존재하며, 이러한 명령은 특정 마이너 버전의 Python 인터프리터를 호출합니다. 이러한 유틸리티가 존재한다면 배포판별 패키지가 이를 활용하는 것이 유용할 수 있습니다. 특정 메이저 버전의 기본 마이너 버전이 변경되더라도 코드가 손상되는 것을 방지할 수 있기 때문입니다. 그러나 플랫폼 간 사용을 목적으로 하는 스크립트는 이러한 유틸리티의 존재에 의존하지 말고, 대상 메이저 버전의 최근 마이너 버전 여러 개에서 테스트해야 하며, 필요한 경우 마이너 버전 간에 존재하는 작은 차이를 보완해야 합니다. 이렇게 하면 시스템 관리자가 서로 매우 유사한 여러 버전의 인터프리터를 설치할 필요가 없어집니다.- 배포판이
pythonX.X바이너리를 제공하는 경우,python2및python3명령은 별도의 바이너리 파일로 제공하기보다 해당 파일 중 하나를 가리켜야 합니다. - 배포판별 패키지는 다른 배포판에서 작동하도록 의도되지 않은 코드에서도
python대신python3(또는python2)를 사용하도록 강력히 권장합니다. 이렇게 하면 배포판이 나중에python명령이 호출하는 Python 인터프리터의 버전을 변경하기로 결정하거나, 시스템 관리자가 배포판 기본값과 다른 메이저 버전의 사용자 지정python명령을 설치하더라도 문제가 줄어듭니다. - 위의 사항을 준수하고 시스템 관리자가
python명령을 변경할 수 있다면,python명령은 항상 인터프리터 바이너리에 대한 링크(또는 링크에 대한 링크)로 구현되어야 하며 그 반대여서는 안 됩니다. 이렇게 하면 시스템 관리자가 설치된python파일을 교체하기로 결정하더라도 이전에 설치된 바이너리를 실수로 삭제하지 않고 교체할 수 있습니다. - Python 2 인터프리터가 점점 덜 사용되더라도, 스크립트가 단순히
python을 사용하는 대신python3규약을 계속 사용하는 것은 여전히 합리적입니다. - 이러한 규약을 준수하면
python명령은 사용자 편의를 위해 대화형 방식으로만 실행되거나, 가상 환경 또는 이와 유사한 메커니즘을 사용할 때만 실행됩니다.
하위 호환성
python2/python3 규약을 따르는 스크립트를 이러한 명령을 지원하지 않는 시스템에서 실행할 경우 잠재적인 문제가 발생할 수 있습니다. 이는 대부분 문제가 되지 않습니다. 시스템 관리자가 이러한 심볼릭 링크를 간단히 만들어 추가적인 문제를 방지할 수 있기 때문입니다. 이는 Python 3 인터프리터로 Python 2 특정 구문이 포함된 스크립트를 실행하려고 할 때나 그 반대의 경우에 발생할 수 있는 때때로 난해한 오류보다 훨씬 명백한 손상입니다.
CPython 참조 인터프리터에의 적용
기술적으로는 새로운 기능이지만, CPython 2.7 버전의 make install 및 make bininstall 명령은 관련 bin 디렉터리에 다음과 같은 심볼릭 링크 체인을 만들도록 조정되었습니다(체인에 나열된 마지막 항목은 실제로 설치된 바이너리이며, 앞의 항목들은 상대 심볼릭 링크입니다):
python -> python2 -> python2.7
python-config -> python2-config -> python2.7-config
macOS 바이너리 설치 프로그램에도 유사한 조정이 이루어졌습니다.
이 기능은 CPython 2.7.3의 기본 설치 과정에 처음 등장했습니다.
CPython 3.x 시리즈의 설치 명령은 이미 적절한 심볼릭 링크를 생성합니다. 예를 들어, CPython 3.2는 다음을 생성합니다:
python3 -> python3.2
idle3 -> idle3.2
pydoc3 -> pydoc3.2
python3-config -> python3.2-config
그리고 CPython 3.3은 다음을 생성합니다:
python3 -> python3.3
idle3 -> idle3.3
pydoc3 -> pydoc3.3
python3-config -> python3.3-config
pysetup3 -> pysetup3.3
기본 설치 프로그램에서 이러한 기능의 구현 진행 상황은 이슈 #12627로 트래커에서 관리되었습니다 ([3]).
PYTHON* 환경 변수에 미치는 영향
python 명령의 대상 선택은 다양한 Python 관련 환경 변수에 대한 배포판의 예상 해석 방식에 암묵적으로 영향을 미칩니다. 해당 site-packages 폴더에서의 *.pth 파일 사용, “사용자별 사이트 패키지” 기능(python -m site 참조), 또는 virtualenv와 같은 더 유연한 도구들은 모두 PYTHONPATH를 직접 사용하는 것보다 시스템에 여러 버전의 Python이 존재하는 상황을 더 잘 허용합니다.
MS Windows 제외
이 PEP는 Windows에 대한 동등한 해결책을 마련하는 것이 여기서 다루기에는 너무 복잡하다고 판단되어, Microsoft Windows와 관련된 제안을 의도적으로 제외합니다. PEP 397과 python-dev 메일링 리스트에서의 관련 논의가 이 문제를 다룹니다.
참고 문헌
Copyright
This document has been placed in the public domain.