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 플랫폼 태그를 만들 것을 제안합니다. 또한 호환되는 플랫폼에서 manylinux2014 배포 패키지를 업로드, 다운로드, 설치할 수 있도록 PyPI와 pip을 모두 업데이트할 것을 제안합니다.

CentOS 6은 현재 지원되는 가장 오래된 CentOS 릴리스이며, 2020년 11월 30일까지 유지보수 업데이트를 받습니다. [1] 그 시점에 수명 종료(end-of-life)에 도달하며, 이후로는 보안 패치와 같은 업데이트가 더 이상 제공되지 않습니다. 그 시점 이후에는 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 대체 아키텍처 특별 관심 그룹(CentOS Alternative Architecture Special Interest Group)이 지원하는 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까지(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 이미지

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

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 플랫폼 태그

초록

근거