Table of Contents

초록
근거
manylinux2014 정책
규정을 준수하는 휠의 컴파일
- Docker 이미지
- Auditwheel
설치 프로그램을 위한 플랫폼 감지
manylinux2010 휠과의 하위 호환성
PyPI 지원
참고 자료
승인
Copyright

번역·라이선스 안내

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

초록

이 PEP는 PEP 513에서 도입된 manylinux2010 태그를 계승할 manylinux2014 플랫폼 태그의 생성을 제안합니다. 또한 PyPI와 pip를 모두 업데이트하여 호환되는 플랫폼에서 manylinux2014 배포 패키지를 업로드하고 다운로드하며 설치할 수 있도록 할 것을 제안합니다.

현재 CentOS 6은 지원되는 CentOS 릴리스 중 가장 오래된 릴리스이며, 2020년 11월 30일까지 유지 보수를 위한 업데이트를 받습니다. [1] 그 시점에 지원이 종료되며 보안 패치와 같은 추가 업데이트는 더 이상 제공되지 않습니다. manylinux2010 이미지에서 빌드된 모든 휠은 그 시점 이후에도 더 이상 사용되지 않는 버전으로 남게 됩니다.

따라서 기존 manylinux 표준을 계속 유지하고, manylinux2014라고 하는 새로운 PEP 425 스타일 플랫폼 태그를 CentOS 7에서 파생하며, manylinux 툴체인, PyPI 및 pip를 업데이트하여 이를 지원할 것을 제안합니다.

관련 PEP 571과 PEP 513이 각각 CentOS 5.11과 CentOS 6에서 허용되는 공유 라이브러리와 그 심볼 버전을 가져온 것과 마찬가지로, manylinux2014 플랫폼 태그는 2024년 6월 30일에 지원이 종료되는 CentOS 7에서 라이브러리와 심볼 버전을 가져옵니다. [1]

manylinuxYYYY 패턴을 계속 사용하도록 하는 여러 장점이 있습니다:

호환 라이브러리가 명확하게 지정된 잘 정의된 Docker 이미지;
여러 릴리스에 걸친 호환성 문제를 조사할 필요가 없음;
아키텍처별 단일 빌드 이미지와 auditwheel 프로필.

단점도 있습니다:

새로운 표준마다 새 PEP를 작성해야 함;
설치 프로그램(예: pip)에 새 플랫폼 태그를 추가해야 함;
설치 프로그램은 특정 릴리스보다 이전의 플랫폼 태그를 설치할 수 없음.

또한 모든 제안에 존재하는 문제도 있으며, 여기에는 Docker 이미지와 해당 auditwheel 프로필을 정의하고 준비하여 릴리스하는 데 필요한 시간과 노력이 포함됩니다. 이러한 문제는 manylinux2010의 긴 배포 과정에서 경험했으며, PEP가 승인된 후 호환 가능한 빌드 환경이 공개되기까지 약 1년이 걸렸습니다. [3]

그러나 이 PEP가 지표가 될 수 있다면, 이제 이 과정은 잘 정의되어 있고 쉽게 반복할 수 있으므로 더 새롭고 업데이트된 플랫폼 태그의 출시 일정을 앞당길 수 있을 것입니다.

`manylinux2014` 정책

다음 기준에 따라 linux 휠이 manylinux2014 태그에 적합한지가 결정됩니다:

휠에는 CentOS 7 또는 CentOS 7 호환 베이스 이미지(예: ubi7)에서 지원되는 다음 아키텍처 중 하나를 대상으로 컴파일된 바이너리 실행 파일과 공유 객체만 포함할 수 있습니다: [4]
```
x86_64
i686
aarch64
armv7l
ppc64
ppc64le
s390x
```
이 목록에는 CentOS 대체 아키텍처 특별 관심 그룹에서 지원하는 ARMv7(armv7l), ARMv8(aarch64) 및 PowerPC(ppc64, ppc64le) 아키텍처와 IBM Z(s390x) 아키텍처에 대한 지원이 추가됩니다. [5]

휠의 바이너리 실행 파일 또는 공유 객체는 다음 목록에 있는 라이브러리를 제외한 외부 제공 라이브러리에 링크할 수 없습니다:

libgcc_s.so.1
libstdc++.so.6
libm.so.6
libdl.so.2
librt.so.1
libc.so.6
libnsl.so.1
libutil.so.1
libpthread.so.0
libresolv.so.2
libX11.so.6
libXext.so.6
libXrender.so.1
libICE.so.6
libSM.so.6
libGL.so.1
libgobject-2.0.so.0
libgthread-2.0.so.0
libglib-2.0.so.0

이 목록은 원래 manylinux2010에 허용된 외부 제공 라이브러리 목록과 동일하지만, 한 가지 예외가 있습니다. libcrypt.so.1은 Fedora 30에서 더 이상 사용되지 않으므로 제거되었습니다. libpythonX.Y는 PEP 513에 설명된 것과 동일한 이유로 계속 포함 대상에서 제외됩니다.

Debian 기반 시스템에서는 다음 패키지가 이러한 라이브러리를 제공합니다:

패키지	라이브러리
libc6	libdl.so.2, libresolv.so.2, librt.so.1, libc.so.6, libpthread.so.0, libm.so.6, libutil.so.1, libnsl.so.1
libgcc1	libgcc_s.so.1
libgl1	libGL.so.1
libglib2.0-0	libgobject-2.0.so.0, libgthread-2.0.so.0, libglib-2.0.so.0
libice6	libICE.so.6
libsm6	libSM.so.6
libstdc++6	libstdc++.so.6
libx11-6	libX11.so.6
libxext6	libXext.so.6
libxrender1	libXrender.so.1

RPM 기반 시스템에서는 다음 패키지가 제공합니다:

패키지	라이브러리
glib2	libglib-2.0.so.0, libgthread-2.0.so.0, libgobject-2.0.so.0
glibc	libresolv.so.2, libutil.so.1, libnsl.so.1, librt.so.1, libpthread.so.0, libdl.so.2, libm.so.6, libc.so.6
libICE	libICE.so.6
libX11	libX11.so.6
libXext:	libXext.so.6
libXrender	libXrender.so.1
libgcc:	libgcc_s.so.1
libstdc++	libstdc++.so.6
mesa	libGL.so.1

휠에 허용된 라이브러리 중 버전이 지정된 심볼도 내보내는 라이브러리에 링크된 바이너리 실행 파일이나 공유 객체가 포함된 경우, 해당 파일은 다음 최대 버전에만 의존할 수 있습니다.:
```
GLIBC_2.17
CXXABI_1.3.7, CXXABI_TM_1 is also allowed
GLIBCXX_3.4.19
GCC_4.8.0
```
예를 들어 manylinux2014 휠에는 GLIBC_2.12 버전의 glibc 심볼이 필요한 바이너리 아티팩트가 포함될 수 있습니다. 이는 GLIBC_2.17의 최대 버전보다 이전 버전이기 때문입니다.
휠이 CPython 2의 어떤 버전 또는 CPython 3.0부터 3.2까지의 버전용으로 빌드된 경우, 유니코드 ABI를 나타내는 CPython ABI 태그를 반드시 포함해야 합니다. 따라서 Python 2용으로 빌드된 manylinux2014 휠은 UCS-4 ABI를 사용하는 인터프리터용으로 빌드되었음을 나타내는 cpy27mu 태그나 UCS-2 ABI를 사용하는 인터프리터용으로 빌드되었음을 나타내는 cpy27m 태그 중 하나를 반드시 포함해야 합니다. (PEP 3149 [7])
휠은 PyFPE_jbuf 심볼을 절대로 요구해서는 안 됩니다. 이는 --with-fpectl configure 플래그를 사용하지 않고 컴파일된 Python을 대상으로 빌드함으로써 달성합니다.

규정을 준수하는 휠의 컴파일

manylinux1과 마찬가지로, auditwheel 도구는 manylinux2014 Docker 컨테이너에서 pip wheel 또는 bdist_wheel로 빌드된 linux 휠에 manylinux2014 플랫폼 태그를 추가합니다.

Docker 이미지

바이너리 linux 휠을 빌드하고 이를 안정적으로 manylinux2014 휠로 변환할 수 있도록 CentOS 7 x86_64를 기반으로 하는 manylinux2014 Docker 이미지를 제공해야 합니다. 이 이미지에는 전체 컴파일러 제품군(gcc, g++, gfortran 4.8.5)이 설치되며, 최신 Python 릴리스와 pip도 함께 제공됩니다.

Auditwheel

auditwheel 도구도 manylinux2014 휠을 생성하도록 업데이트됩니다. [8] 그 동작과 목적은 그 외에는 PEP 513에서 변경되지 않습니다.

설치 프로그램을 위한 플랫폼 감지

플랫폼은 PEP 513에서 설명한 _manylinux 모듈에 manylinux2014_compatible 불리언 속성을 정의할 수 있습니다. 이 속성이 False이면 해당 플랫폼은 manylinux2014와 호환되지 않는 것으로 간주합니다.

_manylinux 모듈을 찾을 수 없거나 manylinux2014_compatible 속성이 없는 경우, 도구는 glibc를 확인하는 방식으로 대체할 수 있습니다. 플랫폼에 glibc 2.17 이상이 있으면 _manylinux 모듈이 달리 지정하지 않는 한 호환되는 것으로 간주합니다.

구체적으로 제안하는 알고리즘은 다음과 같습니다.:

def is_manylinux2014_compatible():
    # Only Linux, and only supported architectures
    from distutils.util import get_platform

    if get_platform() not in [
        "linux-x86_64",
        "linux-i686",
        "linux-aarch64",
        "linux-armv7l",
        "linux-ppc64",
        "linux-ppc64le",
        "linux-s390x",
    ]:
        return False

    # Check for presence of _manylinux module
    try:
        import _manylinux

        return bool(_manylinux.manylinux2014_compatible)
    except (ImportError, AttributeError):
        # Fall through to heuristic check below
        pass

    # Check glibc version. CentOS 7 uses glibc 2.17.
    # PEP 513 contains an implementation of this function.
    return have_compatible_glibc(2, 17)

`manylinux2010` 휠과의 하위 호환성

관련 PEP 513에서 설명한 것처럼, manylinux1에 허용되는 라이브러리에 대해 지정된 심볼 버전은 상한을 이룹니다. 이 PEP에서 manylinux2014에 대해 정의한 심볼 버전에도 동일하게 적용됩니다. 그 결과 manylinux1 및 manylinux2010 휠은 manylinux2014 휠로 간주됩니다. 따라서 manylinux2014 플랫폼 태그를 인식하는 pip는 사용 가능한 manylinux2014 휠이 없을 때 manylinux2014 플랫폼에 manylinux2010 휠을 설치합니다. 태그가 명시적으로 설정된 경우에도 마찬가지입니다.

PyPI 지원

PyPI는 manylinux2010을 허용하는 것과 동일한 방식으로 manylinux2014 플랫폼 태그가 포함된 휠의 업로드를 허용해야 합니다.

기술적으로 가능하다면 PyPI는 manylinux2014휠의 호환성을 검증하려 시도해야 하지만, 그 기능이 이 PEP 채택의 필수 조건은 아닙니다.

패키지 작성자는 규격을 준수하지 않는 manylinux2014휠을 PyPI에 업로드해서는 안 되며, PyPI가 규격을 준수하지 않는 휠의 업로드를 차단하기 시작할 수 있다는 점을 알고 있어야 합니다.

Python 개선 제안 한국어 번역

PEP 599 – manylinux2014 플랫폼 태그

초록

근거