Following system colour scheme Selected dark colour scheme Selected light colour scheme

Python 개선 제안 한국어 번역

PEP 491 – Wheel 바이너리 패키지 형식 1.9

Author:
Daniel Holth <dholth at gmail.com>
Discussions-To:
Distutils-SIG list
Status:
Deferred
Type:
Standards Track
Topic:
Packaging
Created:
16-Apr-2015
Table of Contents

번역·라이선스 안내

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

초록

이 PEP는 “wheel”이라고 하는 Python용 빌드 패키지 형식의 두 번째 버전을 설명합니다. Wheel은 Python에 특화된 재배치 가능한 패키지 형식을 제공하여, 매번 소스에서 다시 빌드하는 것보다 더 빠르고 예측 가능하게 소프트웨어를 설치할 수 있도록 합니다.

Wheel은 특수한 형식의 파일 이름과 .whl확장자를 가진 ZIP 형식 아카이브입니다. 여기에는 특정 설치 체계에 따라 PEP 376에 정의된 방식으로 설치되는 것과 거의 동일한 단일 배포 패키지가 포함됩니다. 단순한 Wheel은 sys.path에 압축을 풀어 바로 사용할 수 있지만, Wheel은 일반적으로 특수한 설치 프로그램으로 설치합니다.

이 버전의 Wheel 사양은 배포 패키지를 여러 다른 디렉터리에 설치하는 기능을 추가하며, 설치가 완료된 후 해당 파일을 찾는 방법도 추가합니다.

PEP 보류

현재 이 PEP는 적극적으로 추진되고 있지 않으며, Python 패키징 개선은 현재 바이너리 아카이브 형식을 추가 사용 사례까지 확장하기보다는 패키지 빌드 과정에 초점을 맞추고 있습니다.

향후 이 PEP에 대한 작업이 재개될 때 다루어야 할 몇 가지 구체적인 요소는 다음과 같습니다.

  • 공식 wheel 형식 정의를 https://packaging.python.org/specifications/ 로 이전하는 작업이며(PEP 566이 https://packaging.python.org/specifications/core-metadata/ 에 대해 수행한 작업과 유사합니다)
  • PEP 자체를 형식의 두 버전 사이에 이루어진 changes와 그러한 변경의 근거에 초점을 맞추도록 업데이트하여, PEP 427에서 변경되지 않은 모든 정보를 반복하지 않도록 합니다.
  • 기존 설치 체계 정의를 사용할 때 기존 설치 프로그램이 사양을 준수할 수 있도록 이 PEP가 의도적으로 작성되었으며, 동시에 바이너리 아카이브 내용에 대한 더 풍부한 분류 체계를 활용하는 새로운 설치 체계 정의를 만들 수도 있음을 명확히 합니다.

근거

Wheel 1.0은 파일을 site-packages와 distutils가 지정한 몇 가지 다른 위치에 설치하는 데 가장 적합하지만, 사용자는 하나의 배포 패키지에서 가져온 파일을 여러 디렉터리에 설치하기를 원합니다. 예를 들어 문서, 데이터, 코드에 대해 별도의 위치를 원할 수 있습니다. 안타깝게도 이러한 설치 위치가 루트 디렉터리를 기준으로 어디에 있어야 하는지에 대해서는 모두가 동의하지 않습니다. 이 버전의 형식은 더 많은 범주를 추가하며, 각 범주는 정책에 따라 서로 다른 대상에 설치할 수 있습니다. 설치된 파일을 런타임에 찾는 것 또한 중요할 수 있으므로, 이 버전의 형식은 설치된 소프트웨어가 읽을 수 있는 방식으로 설치 경로를 기록하는 방법도 추가합니다.

세부 사항

‘distribution-1.0-py32-none-any.whl’ Wheel 설치

Wheel 설치는 개념적으로 두 단계로 구성됩니다.

  • 압축을 풉니다.
    1. distribution-1.0.dist-info/WHEEL을 구문 분석합니다.
    2. 설치 프로그램이 Wheel-Version과 호환되는지 확인합니다. 다음의 경우 경고합니다. 부 버전이 더 크면 경고하고, 주 버전이 더 크면 중단합니다.
    3. Root-Is-Purelib == ‘true’인 경우 아카이브를 purelib에 압축 해제합니다. (site-packages).
    4. 그 외에는 아카이브를 platlib (site-packages)에 풉니다.
  • 배포합니다.
    1. 압축을 푼 아카이브에는 distribution-1.0.dist-info/ 및 데이터가 있는 경우 distribution-1.0.data/가 포함됩니다.
    2. distribution-1.0.data/의 각 하위 트리를 해당 대상 경로로 이동합니다. distribution-1.0.data/의 각 하위 디렉터리는 대상 디렉터리 딕셔너리의 키이며, 예를 들어 distribution-1.0.data/(purelib|platlib|headers|scripts|data)와 같습니다.
    3. #!python으로 시작하는 스크립트를 올바른 인터프리터를 가리키도록 업데이트합니다. (참고: Python 스크립트는 일반적으로 패키지 메타데이터로 처리되며, wheel에 있는 그대로 포함되지 않습니다.)
    4. distribution-1.0.dist.info/RECORD에 설치된 경로를 업데이트합니다.
    5. 비어 있으면 distribution-1.0.data디렉터리를 제거합니다.
    6. 설치된 모든 .py를 .pyc로 컴파일합니다. (제거 프로그램은 RECORD에 언급되지 않았더라도 .pyc를 제거할 수 있을 만큼 영리해야 합니다.) 충분해야 합니다.)

실제로 설치 프로그램은 일반적으로 임시 distribution-1.0.data/ 디렉터리를 작성하지 않고 아카이브에서 파일을 대상 위치로 직접 추출합니다.

권장 설치 프로그램 기능

#!python을 다시 작성합니다.
wheel에서는 있는 그대로의 스크립트가 {distribution}-{version}.data/scripts/에 패키징됩니다. scripts/의 파일 첫 줄이 정확히 b'#!python'으로 시작하면 올바른 인터프리터를 가리키도록 다시 작성합니다. 아카이브가 Windows에서 생성된 경우 Unix 설치 프로그램은 이러한 파일에 +x 비트를 추가해야 할 수 있습니다.

b'#!pythonw' 관례가 허용됩니다. b'#!pythonw'는 콘솔 스크립트가 아닌 GUI 스크립트를 나타냅니다.

스크립트 래퍼를 생성합니다.
Python 스크립트는 패키지 메타데이터에서 module:callable 문자열로 표현되는 경우가 더 일반적이며, wheel 아카이브의 scripts 디렉터리에 있는 그대로 포함되지 않습니다. 이러한 유형의 스크립트는 설치 프로그램이 플랫폼별 래퍼를 생성할 기회를 제공합니다.

권장 아카이버 기능

아카이브의 끝에 .dist-info를 배치합니다.
아카이버는 .dist-info파일을 물리적으로 아카이브의 끝에 배치하는 것이 권장됩니다. 이를 통해 전체 아카이브를 다시 작성하지 않고 메타데이터를 수정하는 기능을 비롯하여 잠재적으로 흥미로운 ZIP 트릭을 사용할 수 있습니다.

파일 형식

파일 이름 규칙

wheel 파일 이름은 {distribution}-{version}(-{build tag})?-{python tag}-{abi tag}-{platform tag}.whl입니다.

배포
배포 이름입니다. 예: ‘django’, ‘pyramid’.
버전
배포 버전입니다. 예: 1.0.
빌드 태그
선택적 빌드 번호입니다. 숫자로 시작해야 합니다. 두 wheel의 버전이 같은 경우의 동률 해결 기준입니다. 지정되지 않은 경우 빈 문자열로 정렬하고, 그렇지 않으면 처음의 숫자들을 숫자로 정렬한 후 나머지를 사전순으로 정렬합니다.
언어 구현 및 버전 태그
예: ‘py27’, ‘py2’, ‘py3’.
ABI 태그
예: ‘cp33m’, ‘abi3’, ‘none’.
플랫폼 태그
예: ‘linux_x86_64’, ‘any’.

예를 들어 distribution-1.0-1-py27-none-any.whl은 ‘distribution’이라는 패키지의 첫 번째 빌드이며, Python 2.7(모든 Python 2.7 구현)과 호환되고, ABI가 없으며(순수 Python), 모든 CPU 아키텍처에서 사용할 수 있습니다.

확장자 앞에 있는 파일 이름의 마지막 세 구성 요소를 “호환성 태그”라고 합니다. 호환성 태그는 패키지의 기본 인터프리터 요구 사항을 나타내며 PEP 425에 자세히 설명되어 있습니다.

이스케이프 및 유니코드

파일 이름의 각 구성 요소는 영숫자가 아닌 문자의 연속 구간을 밑줄 _로 바꾸어 이스케이프합니다.:

re.sub("[^\w\d.]+", "_", distribution, re.UNICODE)

아카이브 파일 이름은 유니코드입니다. 패키징 도구는 ASCII 패키지 이름만 지원할 수 있지만, 이 명세에서는 유니코드 파일 이름을 지원합니다.

아카이브 inside에 있는 파일 이름은 UTF-8로 인코딩됩니다. 일반적으로 사용되는 일부 ZIP 클라이언트는 UTF-8 파일 이름을 올바르게 표시하지 않지만, ZIP 명세와 Python의 zipfile 모두 해당 인코딩을 지원합니다.

파일 내용

배포판 이름을 패키지 이름으로, 예를 들어 beaglevote로 대체하고 버전을 해당 버전으로, 예를 들어 1.0.0으로 대체했을 때, wheel 파일의 내용은 다음으로 구성됩니다.

  1. 아카이브의 루트인 /에는 WHEEL에 지정된 대로 purelib 또는 platlib에 설치할 모든 파일이 포함됩니다. purelib와 platlib은 일반적으로 모두 site-packages입니다.
  2. {distribution}-{version}.dist-info/에는 메타데이터가 포함됩니다.
  3. {distribution}-{version}.data/은 아직 다루지 않은 비어 있지 않은 각 설치 스킴 키마다 하나의 하위 디렉터리를 포함하며, 하위 디렉터리 이름은 설치 경로 딕셔너리의 인덱스입니다(예: data, scripts, include, purelib, platlib).
  4. Python 스크립트는 스크립트 래퍼 생성 및 설치 시 #!python 재작성을 사용하려면 scripts에 나타나야 하며 정확히 b'#!python'으로 시작해야 합니다. 스크립트는 확장자를 가질 수도 있고 가지지 않을 수도 있습니다.
  5. {distribution}-{version}.dist-info/METADATA는 Metadata 버전 1.1 이상 형식의 메타데이터입니다.
  6. {distribution}-{version}.dist-info/WHEEL은 동일한 기본 key: value 형식으로 아카이브 자체에 관한 메타데이터입니다.:
    Wheel-Version: 1.9
Generator: bdist_wheel 1.9
Root-Is-Purelib: true
Tag: py2-none-any
Tag: py3-none-any
Build: 1
Install-Paths-To: wheel/_paths.py
Install-Paths-To: wheel/_paths.json
  7. Wheel-Version은 Wheel 사양의 버전 번호입니다.
  8. Generator는 아카이브를 생성한 소프트웨어의 이름이며, 선택적으로 해당 소프트웨어의 버전도 포함합니다.
  9. Root-Is-Purelib은 아카이브의 최상위 디렉터리를 purelib에 설치해야 하면 true이고, 그렇지 않으면 루트를 platlib에 설치해야 합니다.
  10. Tag는 휠의 확장된 호환성 태그입니다. 이 예에서는 파일 이름에 py2.py3-none-any가 포함됩니다.
  11. Build는 빌드 번호이며, 빌드 번호가 없으면 생략됩니다.
  12. Install-Paths-To는 아카이브를 기준으로 한 위치이며, 설치 스킴의 각 범주에 대한 설치 시 경로로 덮어쓰입니다. 설치 경로 섹션을 참조하십시오. 0회 이상 나타날 수 있습니다.
  13. wheel 설치 프로그램은 Wheel-Version이 지원하는 버전보다 높으면 경고해야 하며, Wheel-Version의 주 버전이 지원하는 버전보다 높으면 실패해야 합니다.
  14. 여러 Python 버전에서 작동하도록 설계된 설치 형식인 Wheel은 일반적으로 .pyc 파일을 포함하지 않습니다.
  15. Wheel에는 setup.py 또는 setup.cfg가 포함되지 않습니다.
디렉터리 .dist-info
  1. Wheel .dist-info 디렉터리에는 최소한 METADATA, WHEEL 및 RECORD가 포함됩니다.
  2. METADATA는 패키지 메타데이터이며, sdists의 루트에 있는 PKG-INFO와 동일한 형식입니다.
  3. WHEEL은 패키지 빌드에 특화된 휠 메타데이터입니다.
  4. RECORD는 휠에 포함된 거의 모든 파일과 해당 보안 해시의 목록입니다. 모든 파일은 PEP 376과는 달리, 자기 자신의 해시를 포함할 수 없는 RECORD를 제외하고 해시를 포함해야 합니다. 해시 알고리즘은 sha256 이상이어야 합니다. 구체적으로 md5와 sha1은 허용되지 않는데, 서명된 휠 파일은 아카이브의 무결성을 검증하기 위해 RECORD의 강력한 해시에 의존하기 때문입니다.
  5. PEP 376의 INSTALLER와 REQUESTED는 아카이브에 포함되지 않습니다.
  6. RECORD.jws는 디지털 서명에 사용됩니다. RECORD에는 언급되지 않습니다.
  7. RECORD.p7s는 S/MIME 서명을 사용하여 휠 파일을 보호하려는 사람을 배려하여 허용됩니다. RECORD에는 언급되지 않습니다.
  8. 압축을 해제하는 동안 휠 설치 프로그램은 RECORD의 모든 해시를 파일 내용과 대조하여 검증합니다. RECORD와 그 서명을 제외하면, 아카이브의 파일 중 RECORD에 언급되지 않았거나 올바르게 해시되지 않은 파일이 하나라도 있으면 설치가 실패합니다.
디렉터리 .data

일반적으로 site-packages 내부에 설치되지 않는 모든 파일은 .dist-info 디렉터리와 동일한 이름에 .data/ 확장자를 붙인 .data 디렉터리로 들어갑니다.:

distribution-1.0.dist-info/

distribution-1.0.data/

디렉터리 .data에는 배포 패키지의 스크립트, 헤더, 문서 등을 포함하는 하위 디렉터리가 들어 있습니다. 설치 중에 이러한 하위 디렉터리의 내용은 대상 경로로 이동됩니다. 설치 중에 이러한 하위 디렉터리의 내용은 해당 목적지 경로로 이동됩니다.

설치 스킴에서 하위 디렉터리를 찾을 수 없는 경우 설치 프로그램은 경고를 출력해야 하며, 표준 unzip 도구로 패키지의 압축을 푼 것처럼 distribution-1.0.data/...에 설치해야 합니다.

설치 경로

distutils 설치 경로에 더해 wheel은 이제 GNU autotools를 기반으로 나열된 범주를 포함합니다. 이 확장된 스킴은 설치 프로그램이 시스템 정책을 구현하는 데 도움이 되지만, 설치 프로그램은 각 범주의 루트를 어느 위치로든 지정할 수 있습니다.

UNIX 설치 스킴은 다음과 같이 범주를 설치 경로에 매핑할 수 있습니다.:

{
    'bindir': '$eprefix/bin',
    'sbindir': '$eprefix/sbin',
    'libexecdir': '$eprefix/libexec',
    'sysconfdir': '$prefix/etc',
    'sharedstatedir': '$prefix/com',
    'localstatedir': '$prefix/var',
    'libdir': '$eprefix/lib',
    'static_libdir': r'$prefix/lib',
    'includedir': '$prefix/include',
    'datarootdir': '$prefix/share',
    'datadir': '$datarootdir',
    'mandir': '$datarootdir/man',
    'infodir': '$datarootdir/info',
    'localedir': '$datarootdir/locale',
    'docdir': '$datarootdir/doc/$dist_name',
    'htmldir': '$docdir',
    'dvidir': '$docdir',
    'psdir': '$docdir',
    'pdfdir': '$docdir',
    'pkgdatadir': '$datadir/$dist_name'
}

패키지가 런타임에 자신의 파일을 찾아야 하는 경우, 설치 프로그램에 해당 파일을 지정된 하나 이상의 파일에 기록하고 또한 아카이브 내 위치를 기준으로 아카이브 자체의 동일한 파일에도 포함하도록 요청할 수 있습니다(따라서 표준 unzip 도구로 압축을 풀거나 아예 압축을 풀지 않더라도 wheel이 올바르게 설치됩니다).

WHEEL 메타데이터에 다음 필드가 포함되어 있다면:

Install-Paths-To: wheel/_paths.py
Install-Paths-To: wheel/_paths.json

wheel 설치 프로그램은 아카이브에서 wheel/_paths.py를 압축 해제하려는 시점에 해당 파일을 설치 시점에 사용되는 실제 경로로 대체합니다. 경로는 생성된 파일에 대해 절대 경로이거나 상대 경로일 수 있습니다.

파일 이름이 .py로 끝나면 Python 스크립트가 기록됩니다. 경로를 얻으려면 스크립트를 반드시 실행해야 하지만, 대략 다음과 같은 형태일 것입니다.:

data='../wheel-0.26.0.dev1.data/data'
headers='../wheel-0.26.0.dev1.data/headers'
platlib='../wheel-0.26.0.dev1.data/platlib'
purelib='../wheel-0.26.0.dev1.data/purelib'
scripts='../wheel-0.26.0.dev1.data/scripts'
# ...

파일 이름이 .json으로 끝나면 JSON 문서가 기록됩니다.:

{ "data": "../wheel-0.26.0.dev1.data/data", ... }

특정 wheel에서 실제로 사용되는 범주만 이 파일에 기록해야 합니다.

이러한 파일은 패키징 라이브러리에 대한 의존성을 추가하지 않고 설치된 패키지가 찾을 수 있는 위치에 기록되도록 설계되었습니다.

서명된 wheel 파일

Wheel 파일에는 디지털 서명을 가능하게 하는 확장된 RECORD가 포함됩니다. PEP 376의 RECORD는 md5sum 대신 보안 해시 digestname=urlsafe_b64encode_nopad(digest) (뒤에 오는 = 문자가 없는 URL 안전 base64 인코딩)를 두 번째 열에 포함하도록 변경되었습니다. 생성된 .pyc 파일과 같은 파일을 포함하여 가능한 모든 항목에 대해 해시를 계산하지만, 자체 해시를 포함할 수 없는 RECORD는 제외합니다. 예를 들면:

file.py,sha256=AVTFPZpEKzuHr7OvQZmhaU3LvwKz06AJw8mT\_pNh2yI,3144
distribution-1.0.dist-info/RECORD,,

서명 파일 RECORD.jws와 RECORD.p7s는 RECORD가 생성된 후에만 추가할 수 있으므로 RECORD에 전혀 언급되지 않습니다. 아카이브의 다른 모든 파일에는 RECORD에 올바른 해시가 있어야 하며, 그렇지 않으면 설치가 실패합니다.

JSON 웹 서명을 사용하는 경우 하나 이상의 JSON Web Signature JSON Serialization (JWS-JS) 서명이 RECORD에 인접한 RECORD.jws 파일에 저장됩니다. JWS는 RECORD의 SHA-256 해시를 서명의 JSON 페이로드로 포함하여 RECORD에 서명하는 데 사용됩니다.:

{ "hash": "sha256=ADD-r2urObZHcxBW3Cr-vDCu5RJwT4CaRTHiFmbcIYY" }

(해시 값은 RECORD에서 사용되는 것과 동일한 형식입니다.)

RECORD.p7s를 사용하는 경우 RECORD의 분리된 S/MIME 형식 서명을 포함해야 합니다.

wheel 설치 프로그램은 디지털 서명을 이해할 필요는 없지만, 추출된 파일 내용에 대해 RECORD의 해시를 반드시 검증해야 합니다. 설치 프로그램이 RECORD에 대해 파일 해시를 확인할 때 별도의 서명 검사기는 RECORD가 서명과 일치하는지만 확인하면 됩니다.

다음을 참조하십시오.

비교 대상은 .egg입니다.

  1. Wheel은 설치 형식이며, egg는 임포트할 수 있습니다. Wheel 아카이브에는 .pyc를 포함할 필요가 없으며, 특정 Python 버전이나 구현에 덜 종속됩니다. Wheel은 이전 Python 버전으로 빌드된 (순수 Python) 패키지를 설치할 수 있으므로, 패키저가 따라잡을 때까지 항상 기다릴 필요가 없습니다.
  2. Wheel은 .dist-info 디렉터리를 사용하며, egg는 .egg-info를 사용합니다. Wheel은 Python 패키징의 새로운 세계 및 그와 함께 등장한 새로운 개념과 호환됩니다.
  3. Wheel은 오늘날의 다중 구현 환경에 맞춰 더욱 풍부한 파일 이름 지정 규칙을 제공합니다. 하나의 wheel 아카이브는 여러 Python 언어 버전과 구현, ABI 및 시스템 아키텍처와의 호환성을 나타낼 수 있습니다. 역사적으로 ABI는 CPython 릴리스에 따라 구체적으로 지정되었지만, wheel은 안정 ABI를 사용할 준비가 되어 있습니다.
  4. Wheel은 무손실입니다. 최초의 wheel 구현인 bdist_wheel은 항상 egg-info를 생성한 다음 이를 .whl로 변환합니다. 기존 egg 및 bdist_wininst 배포판을 변환하는 것도 가능합니다.
  5. Wheel에는 버전이 지정됩니다. 모든 wheel 파일에는 wheel 사양의 버전과 해당 파일을 패키징한 구현이 포함됩니다. 다음 마이그레이션은 간단히 Wheel 2.0으로 진행할 수 있기를 바랍니다.
  6. Wheel은 다른 Python에 대한 참조입니다.

FAQ

Wheel은 .data 디렉터리를 정의합니다. 모든 데이터를 그곳에 넣어야 합니까?

이 사양은 코드를 어떻게 구성해야 하는지에 대해 특정한 견해를 제시하지 않습니다. 일반적으로 site-packages 내부나 PYTHONPATH에 설치되지 않는 모든 파일을 위한 장소가 .data 디렉터리일 뿐입니다. 다시 말해, those 파일은 대개 wheel’s .data 디렉터리에 배포되지 않더라도 pkgutil.get_data(package, resource)를 계속 사용할 수 있습니다.

Wheel에는 왜 첨부 서명이 포함됩니까?

첨부 서명은 아카이브와 함께 이동하므로 분리된 서명보다 편리합니다. 개별 파일에만 서명하므로 서명을 무효화하지 않고 아카이브를 다시 압축할 수 있으며, 전체 아카이브를 다운로드하지 않고도 개별 파일을 검증할 수 있습니다.

Wheel은 왜 JWS 서명을 허용합니까?

JWS가 그 일부인 JOSE 사양은 구현하기 쉽도록 설계되었으며, 이는 wheel의 주요 설계 목표 중 하나이기도 합니다. JWS는 유용하고 간결한 순수 Python 구현을 제공합니다.

Wheel은 왜 S/MIME 서명도 허용합니까?

기존 공개 키 인프라를 wheel과 함께 사용해야 하거나 사용하려는 사용자를 위해 S/MIME 서명을 허용합니다.

서명된 패키지는 안전한 패키지 업데이트 시스템에서 기본적인 구성 요소에 불과합니다. Wheel은 그 구성 요소만을 제공합니다.

“purelib”와 “platlib”의 차이는 무엇입니까?

Wheel은 일부 플랫폼에서 중요한 의미를 갖는 “purelib”와 “platlib”의 구분을 유지합니다. 예를 들어, Fedora는 순수 Python 패키지를 ‘/usr/lib/pythonX.Y/site-packages’에 설치하고, 플랫폼 종속적인 패키지를 ‘/usr/lib64/pythonX.Y/site-packages’에 설치합니다.

모든 파일이 {name}-{version}.data/purelib에 위치한 “Root-Is-Purelib: false” wheel은 동일한 파일이 루트에 위치한 “Root-Is-Purelib: true” wheel과 동등하며, “purelib”와 “platlib” 두 범주 모두에 파일을 두는 것도 허용됩니다.

실제로는 wheel이 순수 Python인지 여부에 따라 “purelib”나 “platlib” 중 하나만을 가져야 하며, 해당 파일들은 “Root-is-purelib”에 적절한 설정이 지정된 상태로 루트에 있어야 합니다.

wheel 파일에서 Python 코드를 직접 임포트하는 것이 가능합니까?

기술적으로, 단순 압축 해제를 통한 설치 지원과 zipimport와 호환되는 아카이브 형식 사용이 결합되어, 일부 wheel 파일은 sys.path에 직접 배치되는 것을 실제로 지원합니다. 그러나 이 동작이 형식 설계의 자연스러운 결과이기는 하지만, 실제로 이에 의존하는 것은 일반적으로 권장되지 않습니다.

첫째, wheel은 실제로 주로 배포 형식으로 설계되어 있으므로, 설치 단계를 건너뛰는 것은 또한 완전한 설치를 전제로 하는 기능(예를 들어, 감사 및 보안 업데이트 목적으로 적절히 추적할 수 있는 방식으로 의존성을 포착하고 관리하기 위해 pip와 virtualenv같은 표준 도구를 사용할 수 있는 것, 또는 적절한 위치에 헤더 파일을 게시함으로써 C 확장을 위한 표준 빌드 메커니즘과 완전히 통합되는 것 등)에 대한 의존을 의도적으로 피하는 것을 의미합니다.

둘째, 일부 Python 소프트웨어는 zip 아카이브에서 직접 실행되는 것을 지원하도록 작성되어 있지만, 여전히 코드가 완전히 설치되었다고 가정하고 작성되는 경우가 흔합니다. 소프트웨어를 zip 아카이브에서 실행하려고 시도함으로써 이 가정이 깨지면, 실패가 모호하고 진단하기 어려운 경우가 많습니다(특히 서드파티 라이브러리에서 발생할 때). 이와 관련된 문제의 가장 흔한 두 가지 원인은, zip 아카이브에서 C 확장을 임포트하는 것이 CPython에서 지원되지 않는다는 점(이는 어떤 플랫폼에서도 동적 로딩 메커니즘이 이를 직접 지원하지 않기 때문입니다)과, zip 아카이브에서 실행할 때 __file__ 속성이 더 이상 일반적인 파일 시스템 경로가 아니라 파일 시스템 상의 zip 아카이브 위치와 아카이브 내부 모듈의 상대 경로를 모두 포함하는 결합 경로를 가리킨다는 점입니다. 소프트웨어가 내부적으로 추상 리소스 API를 올바르게 사용하는 경우에도, 외부 구성 요소와의 인터페이싱에는 여전히 실제 디스크상의 파일이 필요할 수 있습니다.

메타클래스, 몽키패칭, 메타패스 임포터와 마찬가지로, 이 기능을 활용해야 한다는 확신이 없다면 거의 확실히 필요하지 않을 것입니다. 그럼에도 불구하고 정말 사용하기로 결정했다면, 많은 프로젝트가 진짜 버그로 받아들이기 전에 완전히 설치된 패키지로 실패를 재현할 것을 요구한다는 점을 유의하십시오.

부록

urlsafe-base64-nopad 구현 예시:

# urlsafe-base64-nopad for Python 3
import base64

def urlsafe_b64encode_nopad(data):
    return base64.urlsafe_b64encode(data).rstrip(b'=')

def urlsafe_b64decode_nopad(data):
    pad = b'=' * (4 - (len(data) & 3))
    return base64.urlsafe_b64decode(data + pad)