PEP, 메일링 리스트 등 정리 https://packaging.python.org/en/latest/discussions/ https://www.pypa.io/en/latest/history/ 연도 주요 사건 & 제안 배경·의의 1998 ‒ 2000 distutils 표준 라이브러리 (Greg Ward) → Python 2.0에 포함 (Python 3.12에서 제거) • setup.py sdist로 소스 배포만 가능 • 바이너리 배포·의존성 관리 기능 부족 2004 ‒ 2008 setuptools / easy_install (Phillip Eby) → .egg 형식 도입 • import-time zip-import 덕분에 “설치 없이” 로드 가능 • 이슈 : 플랫폼·ABI 태그 부재, script entry point 처리 문제, namespace 미지원 2008 ‒ 2011 Packaging Summit (PyCon 2008) → Distutils-SIG PEP 345 (메타데이터 1.2), PEP 376 (설치 레코드), PEP 386 (버전 규칙) 등 • “egg의 한계 + 서로 다른 빌드·배포 파편화” 해결 필요성 확인 • Python Packaging Authority (PyPA) 결성, distutils2 실험(결국 폐기) 2012 Wheel 규격 제안 (Daniel Holth) → PEP 425 (호환 태그), PEP 427 (wheel 1.0), PEP 426 (메타데이터 1.3, 이후 Core Metadata로 발전) 채택 주요 개발목표 (1) OS/ABI/파이썬 버전별 호환 태그로 정확한 바이너리 제공 (2) 단순 파일 복사만으로 빠른 설치 (3) zip-safe 포맷이지만 import-time hack 없음 (egg 대비 개선) (4) 설치 기록은 PEP 376 표준으로 통합 2013 wheel 0.9‒1.0 릴리즈 → pip install <pkg>.whl 지원 (pip 1.4), setup.py bdist_wheel 커맨드 보급 • Linux binary 문제를 해결하기 위해 곧이어 manylinux 제안 논의 시작 2014 ‒ 2016 PEP 425 Platform Tags 확대, PEP 513 (manylinux1), PEP 571 (manylinux2010) 등 • 리눅스 배포판 간 glibc 호환 계층 정의 → Wheel이 C-extension 생태계의 기본 배포 형식으로 자리잡음
버전, 의존성 등 (PEP 566, email-like format) ⬝ WHEEL: Wheel 포맷 버전, 생성자 정보, 구현체 태그 등 ⬝ RECORD: 모든 파일 목록 + 해시값 + 크기 (서명 가능) ⬝ entry_points.txt: 콘솔 스크립트 등 entry point 정의 ⬝ top_level.txt: top-level import 가능한 패키지 목록 Python Wheel 규격 파일 내부 구조 PEP 427: Python 패키지의 binary distribution format (.whl) Source : https://peps.python.org/pep-0427/ package_name/ __init__.py ... package_name-1.0.0.dist-info/ METADATA WHEEL RECORD top_level.txt (optional) entry_points.txt (optional) ...
위한 플랫폼 태그 형식 ⬝ Python tag: 지원하는 인터프리터 (cp313, py3 등) ⬝ ABI tag: ABI 호환성 (cp313, abi3, none) ⬝ Platform tag: 운영체제 및 아키텍처 ⬝ 순수 Python: any ‒ Linux 예시: manylinux2014_x86_64, musllinux_1_1_x86_64, manylinux_2_28_aarch64 ‒ macOS 예시: macosx_10_9_x86_64, macosx_10_15_universal2 ‒ Windows 예시: win_amd64, win32 Source : https://peps.python.org/pep-0425/ {distribution}-{version}(-{build_tag})?-{python_tag}-{abi_tag}-{platform_tag}.whl
https://www.pypa.io/en/latest/ 역사 ⬝ 2002년 “Cheese Shop” — Richard Jones, Juergen Hermann가 CPAN과 유사한 Python 패키지 공유 공간으로 시작 ⬝ 2003 ~ 2005년 PEP 301, PEP 314로 메타데이터 포맷 표준화 → 자동 설치 도구(easy_install) 등장 ⬝ 2016년 warehouse 프로젝트로 전면 재작성 → 2018년 공식 서비스 전환 주요 기능 ⬝ 패키지 업로드·배포 ‒ twine upload, Trusted Publisher (OIDC) 등의 배포자 인증 방식 지원 ‒ Yanked Release, Project Transfer 기능으로 릴리즈 관리 ⬝ 메타데이터·검색 API ‒ Simple API (PEP 503) : 경량 인덱스, 모든 Python 클라이언트 호환 ‒ JSON & XML-RPC : 상세 메타데이터·통계 조회 ‒ PEP-658 : requires_dist 등 의존성 미리 노출해 설치 최적화
주요 agenda ⬝ How to reinvent the wheel (PEP 777) ‒ Wheel 2.0 등 호환성 깨지는 포맷 변화를 안전히 도입하기 위한 규칙(Wheel-Version 필드, .whlx 확장자 등) 마련 ⬝ Wheel Variants ‒ GPU 드라이버·CPU ISA 등 하드웨어 특화 속성을 갖는 여러 Variant Wheel을 배포하고, 플러그인이 시스템 특성을 감지해 최적 wheel을 자동 선택 ‒ 해시 기반 식별·Provider Plugin 체계로 태그 폭발 없이 세분화된 호환성 표현을 가능케 해 사용자·배포자 관리 부담 감소 ⬝ Index Prioritization (PEP 766) ‒ 다중 인덱스 사용 시 버전 우선과 인덱스 우선 두 해석 모드를 명확히 정의해 pip와 uv 동작 차이 해소 ‒ “회사 내부 인덱스 → PyPI” 같은 우선순위를 선언 가능하게 만들어 예측 가능한 패키지 의존성 해결 동작과 보안 정책 지원 ⬝ Native Library Loader ‒ 여러 wheel이 공유하는 OpenBLAS 등 native library를 중복 적재하지 않고 공통 로더로 안전하게 로드·버전 협상하도록 표준화 ‒ importlib 유사 고수준 API로 플랫폼별 로딩·RPATH 문제를 통일, 패키지 크기·메모리 사용 감소와 보안 검사 일원화 ⬝ Default Extra (PEP 771) ‒ 사용자가 extras를 명시하지 않을 때 패키지가 권장 extras 집합을 기본으로 자동 설치하도록 하여 사용자 경험 개선 ⬝ Build Isolation Passthrough ‒ 빌드 격리 환경에 호스트의 컴파일러·헤더·라이브러리 등을 선택적으로 패스스루해 CUDA·Rust 등 ABI 의존 패키지의 빌드 실패를 줄이자는 제안
777) 문제 인식 ⬝ 현재 wheel 포맷(1.0)은 10년 이상 사용되어 새로운 기능을 수용하면서도 구형 도구를 위한 하위호환 고려 필요 제안하는 해결 방법 ⬝ Wheel-Version 필드 도입: METADATA 파일에 Wheel 버전을 명시하여, 설치 도구가 호환성을 사전에 판단할 수 있도록 함 ⬝ 파일 확장자 변경: 향후 Wheel 2.0 이상은 .whl 대신 .whlx 확장자를 사용하여, 구형 도구가 새로운 포맷을 무시하도록 유도 ⬝ 설치 도구 및 해석기(resolver) 동작: 호환되지 않는 Wheel 버전은 설치 대상에서 제외한 후 사용자에게 경고 ⬝ 기존 pip 및 패키지 설치 도구와의 하위호환성을 유지하기 위한 조건들 ‒ importlib.metadata와의 호환성 유지 ‒ ZIP 포맷 유지 및 .dist-info 디렉토리는 압축 없이 루트에 위치 ‒ 표준 라이브러리에 포함된 압축 포맷만 사용 ⬝ 기대 효과 ‒ Wheel 포맷의 진화를 위한 기반 마련 ‒ 설치 도구의 안정성과 사용자 경험 향상 ‒ 다양한 플랫폼 및 하드웨어 지원을 위한 확장성 확보
인식 ⬝ pip과 uv 등 Python 패키지 설치 도구들이 다중 인덱스를 처리하는 방식이 서로 달라 예기치 않은 결과 발생 ⬝ 두 가지 우선순위 모델 존재 ‒ Version Priority: 모든 인덱스를 병합하여 가장 적합한 버전 선택 ‒ Index Priority: 인덱스 우선순위에 따라 순차적으로 먼저 발견된 패키지를 선택 ⬝ Index Priority의 장점 ‒ 명시적인 index 우선순위를 클라이언트 도구가 일관되게 설정·적용 ‒ 예기치 않은 업데이트를 방지하고 예측 가능한 설치 결과 제공 제안하는 해결 방법 ⬝ pip, uv 업데이트: 명시적인 index priority를 고려하도록 기본 메커니즘 적용 ⬝ 도입 고려사항 ‒ 캐시 및 잠금 파일(lockfile) 시스템의 변경 필요 ‒ 인덱스 그룹 및 우선순위 설정을 위한 사용자 정의 구성 지원 필요 ⬝ 기대 효과 ‒ 보안 강화: 명시적으로 Index Priority는 사용자가 인덱스 간의 신뢰 계층을 명시할 수 있게 하여 의존성 혼동 공격을 제한
현행 wheel 포맷은 다양한 하드웨어 및 플랫폼 요구사항을 충족하기에 부족하여, 플랫폼 특화 패키지 배포를 위한 체계적인 메커니즘 도입 필요 제안하는 해결 방법 ⬝ variantlib 개발 + pip 업데이트 ‒ Wheel Variant 시스템: 동일한 패키지 버전에 대해 하드웨어 특화된 여러 Wheel을 구분하여 제공 ‒ Provider Plugin: 설치 시 플랫폼 속성을 동적으로 감지하여 최적의 Wheel Variant를 추천 ‒ 해시 기반 식별자: Wheel 파일명에 해시를 추가하여 명확한 변형 구분 및 호환성 유지 ⬝ 기대 효과 ‒ 설치 도구의 변경 없이도 다양한 하드웨어에 최적화된 패키지 제공 가능 ‒ 패키지 유지보수자의 부담 최소화 및 생태계의 일관성 유지 python -m build ... auditwheel repair ... variantlib make-variant ... python3 -m pip install \ pep-xxx-wheel-variants variant-aware PyPI (or MockHouse) pip install ... twine upload ...
워킹그룹 Variant support variantlib ⬝ 실제로 확장 플랫폼 태그를 포함시켜주는 wheel 파일 빌드 도구 ‒ 이미 빌드된 .whl 파일에 variants.json 파일을 추가하고 variant 속성 목록으로부터 해시값을 계산하여 파일명의 플랫폼 태그 뒤에 붙여줌 ‒ 빌드 과정 자체에 개입하지 않고 결과물의 태그만 업데이트하므로 기존 빌드 파이프라인을 거의 그대로 활용할 수 있음 https://www.youtube.com/watch?v=1Oki8vAWb1Q
⬝ 해시 형태로 된 variant tag를 인식하면 pypi에서 variants.json 인덱스 파일을 먼저 다운로드하고, 해시값이 가리키는 property 값들을 가져옴 ‒ Provider plugin들이 제공하는 property 목록과 대조하여 현재 시스템에 가장 최적의 wheel을 선택하여 다운로드하고 설치 https://www.youtube.com/watch?v=1Oki8vAWb1Q
@ Meta 먼로파크 오피스 1부 ‒ Case Sharing & 주요 Agenda 초안 제안자 설명 세션 ⬝ 주요 커뮤니티·기업별 case sharing 세션 ‒ PyTorch: 패키지 크기가 너무 커지는 문제, default extras, symlink ‒ Jax: C++ wheel 관련 표준 필요성, extra 패키지들이 main 패키지 업데이트 시 함께 업데이트되지 않는 문제 ‒ Quansight: SIMD 관련 플랫폼 태깅 필요성, native 모듈 위한 build backend 지원 ‒ RedHat: 보안 상 모든 wheel을 직접 소스 빌드하는데 sdist만으론 부족 (임의로 커스터마이징해둔 빌드 스크립트들과 본인들이 강제하는 빌드 환경과의 충돌 등), Bazel/buck 같은 hermetic sandbox 내에 CUDA를 넣기 어려운 점 ‒ AMD: zip 압축 방식은 GPU나 개발용 라이브러리에서 효율이 나쁨 ‒ Astral: vLLM-PyTorch 버전 강결합 이슈, 가속기 하드웨어 의존성 표기방법 필요 ‒ Anaconda: CPU instruction set (AVX2, SSE4.2 등) 의존성 표기방법 필요, sigstore나 attestation 같은 보안 검증 기능 필요성 ‒ GPU Mode: AOT vs. JIT, PyTorch와 써드파티 C++ 코드 결합 이슈
@ Meta 먼로파크 오피스 1부 ‒ Case Sharing & 주요 Agenda 초안 제안자 설명 세션 ⬝ Wheel variants ⬝ Index priority ⬝ Symlink support & reinventing the wheel 2부 ‒ Wheel variants, index priority 두 주제에 대한 소그룹 토의 ⬝ 화이트보드와 함께 자유롭게 질의응답 및 아이디어 제안 토의 진행 ⬝ Wheel Variants ‒ provider 간의 우선순위 이슈 (여러 개의 provider가 동시에 동일한 provider identifier를 지원한다고 주장하면 어떻게 할 것인가?) ‒ requirements.txt나 lock 파일에서 variantlib tag를 어떻게 표현할 것인가? 참고 자료 https://wheelnext.dev/summits/2025_03/slidedecks_and_resources/
@ 온라인 미팅 다가오는 PyCon US 발표 및 Packaging Summit 관련 내용 사전 공유 ⬝ variantlib으로 태깅된 whl 파일들 서빙하는 MockHouse 프로젝트 공개 ‒ https://mockhouse.wheelnext.dev/ ⬝ provider 플러그인이 현재 시스템 스캔하여 태그 집합 생성하는 기능 추가 ⬝ 사용자가 variants.toml 파일을 통해 feature 간 우선순위 정의할 수 있도록 확장 래블업 건의사항 ⬝ PBS (python-build-standalone) 프로젝트에서 호환성 때문에 일부러 과거 kernel 버전을 기준으로 빌드하는 바람에 최신 syscall (예: pidfd_open() 등) 못 쓰는 문제를 해결할 수 있도록 weak symbol을 도입할 필요가 있음 ⬝ CUDA 런타임 버전뿐만 아니라 NVIDIA Driver 버전도 매칭할 수 있으면 좋겠음 (NVML API를 직접 사용하는 경우 고려) ⬝ 일관된 방법으로 C/C++ symbol 버전 충돌 문제를 피할 수 있는 native library loader 규격도 정의할 필요가 있음 참고 자료 https://wheelnext.dev/slidedecks_resources/
PyCon US 세션 발표 ⬝ PEP 13에 따른 governance 체계를 PyPA에 도입 ⬝ 3.14부터 모바일 환경 CPython 구현체들을 Tier 2로 상향 / wheel variants 등 자유 발제 ⬝ Vendored package가 있는 경우 라이선스 다중 표기 가능하게 하는 옵션 ⬝ “Partial” dynamic metadata ⬝ SBOM 뽑아내기 위해 빌드 VM 자체를 감싸는 네트워크 프록시 샌드박스 구축 ⬝ PyTorch + vLLM 제발 어떻게 좀 쉽게 배포할 수 있을 것인가... ⬝ pyodied + emscripten 기반 wasm 빌드에 대한 플랫폼 태그 정의를 pip, uv에 반영하기 ⬝ 직접 발제한 내용:
향후 1~2년 내로 CUDA 및 다양한 가속기 하드웨어에 특화된 wheel 설치 과정이 pip install 하나로 해결되는 날이 올 수 있을까? 워킹그룹 구도 ⬝ Python Packaging Authority 산하 SIG 형식이지만 실질적으로는 Meta와 NVIDIA가 주도 ‒ 본인들도 이 사실을 잘 인지하고 있고, 그래서 더욱 적극적으로 다양한 목소리를 들을 기회를 마련 노력 ⬝ 아무래도 full-time으로 이 일을 본인 업무로 삼아서 진행하는 사람의 존재 유무가 추진력에 큰 차이를 가져옴 느낀 점 ⬝ 실리콘밸리 빅테크들이 어떻게 ‘표준화’라는 주제를 다루는지 경험할 기회 ⬝ 우리나라가 AI 시장에서 할 수 있는 일이 전세계 기준으로 굉장히 큰 편이라, 한국 오픈소스 커뮤니티에서도 이런 논의에 좀더 적극 참여 필요 ‒ 중국·미국하고만 비교하면 아쉬워보이지만 AI 반도체부터 응용 서비스까지 모든 스택을 개발·상용화 가능한 몇 안 되는 나라 ⬝ Right place, right time에 가서 이야기하는 것의 중요성 ‒ 똑같은 아이디어라도, Packaging Summit에 직접 참가하여 대면으로 이야기하기 vs. discuss.python.org에 글로만 적기
SiteGround - Reliable hosting with speed, security, and support you can count on.
achimnol
utgwkk
andpad
licux
o0h
suikabar
skrb
nrslib
k1mu21
irof
satohjohn
ukin0k0
j_lee
lcolladotor
katiecoart
ipullrank
eileencodes
andyhume
aleyda
schroneko
cassininazir
jnunemaker
akademiya2063
irinanazarova
addyosmani
