[Python Korea] PyCon US 2026 후기 공유회

Transcript

1. PyCon US 2026 Packaging Summit Joongi Kim @ Lablup Inc.
2. • https://us.pycon.org/2026/events/packaging summit/ • 파이썬 프로그램을 배포하는 과정에 관여하는 모든 stakeholder들이 모여 방향성 논의 및 아이디어 공유 setuptools, pip, conda, poetry, uv 같은 의존성 관리 도구의 메인테이너·개발자들 (배포가 복잡한) numpy, torch, xgboost 등 각종 라이브러리 및 앱의 메인테이너·개발자들 리눅스 배포판의 downstream 패키지 관리자들 다양한 패키지를 설치하는 사용자들 • 한 나절 4 5시간 가량 별도 세션룸에서 워크샵 형태로 진행되는 형식 주요 주제 발표 3~4개, Lightning Talks, 테이블 단위 주제 토론 시간 Packaging Summit? @jezdez (Jannis Leidel) @cam-gerlach (C.A.M. Gerlach) @pradyunsg (Pradyun Gedam)
3. • Revisiting Wheel 2.0 and Better Compression Emma Smith https://docs.google.com/presentation/d/1zh-3FkCg2cSMp3QD5oFji5sebeJlu3Hg_d- maYe7Pno/edit?usp=sharing wheel 형식 변경은 모두의 CI를 깨뜨릴 위험이 큼 PEP 777로 최소한의 변경 → 이후 변경은 개별 sub-PEP로 하나씩 제안 휠은 그대로 ZIP·기존 메타데이터 포맷을 유지하고, 전환 시점은 각 인덱스가 결정한다(약 5년 예상) Zstandard 압축 도입 기대 효과 : 상위 1000개 프로젝트 기준 용량 25% 감소, 약 100PB 대역폭과 36년치 압축 해제 시간 절약 아직 바로 도입하기 어려운 이유 : pip와 같은 도구들은 C 의존성 추가를 피하고 싶어함 • zstd가 표준 라이브러리에 도입되어 문제가 해결됨 (Python 3.14) 제안 : tar.zst를 ZIP 안에 비압축 저장하는 방식(아카이브 속 아카이브)을 통해 호환성 확보 질의응답 다른 압축 포맷(예: xz) 허용 여부, uv와 같이 비압축 메타데이터를 가정하는 경우 호환 보장, conda에서 사용한 스트리밍 방식 zip 직접 쓰기 메커니즘 아이디어, ... Main Talk 1
4. • Limiting vectors and incentives for abuse Mike Fiedler https://www.dropbox.com/scl/fi/kg4fr4gc1t9c27sbbqvig/PyCon-US-2026-Packaging-Summit-Mike- Fiedler.pdf?rlkey=4u3v4n201ja82ugkdydf0jy6f&dl=0 PyPI 업로드 폭증 AI 효과로 신규 업로드가 월 8천 개에서 2만 4천 개로 급증, 사람이 일일이 검토하기 어려운 상황 이미 시행 중인 완화책 : Trusted Publishing 확대, rate-limit 강화(시간당 40개 → 하루 4개), archived 상태 도입, 미사용 토큰 삭제 안내 고민거리 영구 저장 상태 : 삭제해도 콜드 스토리지에 그대로 남는다(실서비스 36TB + 비참조 36TB). 바로 진짜 삭제할지 아니면 일정 기간 유예 후 삭제할지? 릴리스 수정 방지 : 동일 버전 악성 파일 덮어쓰기를 막기 위해 일정 기간(예: 7일) 후 릴리스 잠금(정당한 wheel backfill은 보장 필요)하는 것이 어떨지? 바이너리 저장소 남용 : PyPI가 Java jar·node_modules·Zig 등을 담는 무료 CDN으로 쓰여 생태계에 부담 Main Talk 2
5. • Encouraging the community to view Packaging in terms of ecosystems, not tools Mahe Iram Khan https://docs.google.com/presentation/d/1qXRO31uQ8mG_IcxDtAtbZ-- u_nSAXlmMEY77FkluyPI/edit?usp=sharing 4년차 conda 메인테이너 경험 : Conda와 Pip은 단순히 2개의 서로 다른 도구가 아니라, 서로 다른 제약 속에서 발전한 별개의 생태계로 보아야 한다. 패키징 역사 distutils → setuptools → 2008년 pip·virtualenv로 이어졌으나, pip은 바이너리 의존성을 제대로 다루지 못하였음. 그 공백을 메우려 2012년 과학 컴퓨팅 커뮤니티에서 언어 비종속·환경 통합 관리자인 Conda가 탄생 (pip 개선이 아니라 다른 문제를 푼 것) 각 생태계는 고유한 관례·도구를 발전시킴 (uv·poetry는 pip 계열, mamba·pixi는 conda 계열) 생태계 파편화 문제 일반 사용자는 도구 수준에서만 경험해 혼란 중립적·공식적 안내 자료와 생태계 간 다리(wheel variant)가 필요 Main Talk 3
6. • Quick update on PEP 772, Packaging Council Barry Warsaw PEP 772(명문화된 Packaging Council 운영 방안)가 SC에서 완전히 승인됨 가을 PSF 이사회 선거와 일정을 맞춰 진행하며, 유권자 검증·선거 절차를 함께 반영할 계획 선거는 각 2주씩 3단계(지명·선거)로 진행. 후보·지명에는 PSF 멤버 자격이 필요 A·B 두 코호트가 2년 격년 주기로 번갈아 선출됨. 관심 있는 이들에게 적극 홍보·후보 참여를 독려 • Mobile packaging update Malcolm Smith 지난 1년 동안 모바일 패키징 생태계의 주요 요소가 모두 갖춰짐 빌드 : cibuildwheel의 Android·iOS 지원 호스팅 : PyPI 새 휠 태그 설치 : 공식 지원까지 완비 개발 도구 확산 : 작년엔 BeeWare 정도였으나 이제 Kivy 등으로 확대 PyPI 내 비중은 아직 낮지만 사용자 요청에 따라 꾸준히 증가 중 목표 : 모바일 Python을 다른 플랫폼만큼 쉽게 만드는 것 Lightning Talk 1 2
7. • Compile to Flit solution to bootstrapping problem Jason Coombs 문제 : build backend는 자기 자신을 bootstrap할 수 없어 의존성을 가질 수 없다 예를 들어 자신이 유지보수하는 Coherent build system은 15개의 의존성이 있음 https://github.com/coherent-oss/system 기존 우회책 : setuptools는 의존성을 벤더링, Flit은 의존성을 아예 두지 않음 새 전략 : "Compile to Flit" 원본 소스코드를 그대로 압축하는 방식으로 쓰지 않고 sdist를 빌드 타겟으로 하되 빌드 시 flit_core를 쓰는 pyproject.toml을 생성하고 메타데이터를 고정 → bootstrapping 문제 해소 사용자는 소스코드를 그대로 빌드하는 것이 아니라, sdist로부터 wheel 빌드를 생성해야 함 결과적으로 sdist 크기가 매우 작아짐. setuptools의 모든 의존성에도 이 기법을 적용할 계획 Lightning Talk 3
8. • How we used the deconstructed pip stack in conda pypi Daniel Holth pip 스택을 분해한 구성요소(unearth, pypa/installer, pypa/build)를 재활용한 conda-pypi를 소개 PyPI와 conda를 혼용하는 환경에서 모든 의존성을 한 곳에서 관리하는 것이 목표 wheel을 빌드해 곧바로 conda 패키지로 변환·설치하고, editable install도 conda 환경에 통합 pip과 달리 conda는 빌드·설치 대상과 다른 Python 환경에서 동작 • A new pure Python dependency resolver nab Damian Shaw https://github.com/notatallshaw/nab uv와 비슷한 수준의 성능을 목표로 하지만 순수 Python으로 작성 https://github.com/sarugaku/resolvelib 메인테이너 경험을 살려서... 아직 매우 초기 구현만 제공하고 있는 상태 Lightning Talk 4 5
9. • Solving environment management for teams and collaborators Dharhas Pothina https://github.com/nebari-dev/nebi CUDA와 같이 컴파일된 라이브러리를 배포하고자 할 때, 파이썬 패키지와 시스템 라이브러리를 하나의 통합 lockfile로 정의·추적하는 Pixi 기반으로, 버전 관리·롤백·환경 공유 등의 기능을 추가하는 프로젝트 https://pixi.prefix.dev/latest/ Conda 생태계 위에 올라타는 방식 Lightning Talk 6
10. • Yoda conditions in PEP 508 markers 버전 범위를 예를 들어 "1.0 <= dependency < 2.0" 같이 쓸 수 있게 하자는 아이디어 (현재는 콤마로 두 조건을 이어서 써야 함) • PEP 803 abi3t: Stable ABI for free threaded Python • Wheel 2.0 and Zstandard compression zip/tar 파서 구현체 차이(예: GNU tar vs. POSIX tar)를 극복하기 위한 zip 바이너리 형식·호환성 강제 여부, 더 큰 파일 크기를 지원하기 위한 ZIP64 도입 여부, zstd seekable 표준 미비 문제, 심볼릭 링크 지원은 표준 라이브러리 CVE 이슈로 우려 등... • Cross platform environments and wheel building Android, iOS, Emscripten, ... • Improving security metadata across ecosystems CVE 추적 호환성 (파이썬 패키지 안에 리패키징된 다른 의존성으로부터 유래하는 경우) 시스템 의존성을 기술할 수 있게 하는 제안이 있었음 (PEP 804) Cooldown : 아이디어는 좋지만, 모두가 이걸 사용하게 되면 역으로 문제 발견이 늦어지는 상황이 발생 가능 SLSA provenance 전파 메커니즘 활용 아이디어 Roundtables
11. More Variants, More Diversity for AI Accelerators Joongi Kim @ Lablup Inc.
12. The Problem Why can't we just do "pip install torch"? PEP 817 Wheel Variants
13. Same Analogy, Same Problem Python Package Index Host CPU Features GPU Features NPU Features pip install Query package list Package index with variant props Variant props from local variant providers Download the matched wheel variant x86_64 :: level :: v3 nvidia :: cuda_version :: 12.8 nvidia :: sm_arch :: 120_real rebellions :: arch :: atom_max furiosa :: arch :: renegade
14. Same Analogy, Same Problem Python Package Index Host CPU Features GPU Features NPU Features pip install Query package list Package index with variant props Variant props from local variant providers Download the matched wheel variant x86_64 :: level :: v3 nvidia :: cuda_version :: 12.8 nvidia :: sm_arch :: 120_real rebellions :: arch :: atom_max furiosa :: arch :: renegade Container Registry Host CPU Features GPU Features NPU Features docker pull Query image list Image index with variant props Variant props from local variant providers Pull the matched container variant x86_64 :: level :: v3 nvidia :: cuda_version :: 12.8 nvidia :: sm_arch :: 120_real rebellions :: arch :: atom_max furiosa :: arch :: renegade
15. • Platfrom variants in OCI Open Container Image https://specs.opencontainers.org/image-spec/image-index/#platform-variants Borrows Golang's build target variant expressions Current Status L No consideration for accelerators
16. • Lablup s Backend.AI adopted a custom tagging ruleset. pytorch:2.12.0-ubuntu24.04-py312 pytorch:2.12.0-ubuntu24.04-cuda13-py312 pytorch:2.12.0-ubuntu22.04-atom-py313 pytorch:2.12.0-ubuntu22.04-... Current Status L Manual client-side selection (exact, partial, ...?) L No standardized tag namings across different vendors L Too long tags for multi- feature-compatible images
17. • Kubernetes DRA Dynamic Resource Allocation stable in v1.35 Prioritized List [stable in v1.35] & DRAListTypeAttributes [alpha in v1.36] Consumed by CEL expressions to generalize matching conditions Specifies alternative combinations of device properties. Updated DRAListTypeAttributes introduces typed values (bools, ints, strings, versions). Current Status L Looks promising, but complexity still left to users (Manual CEL expression writing...)
18. • Why not just reuse a community driven, community proven standard? https://peps.python.org/pep-0817/ PEP 817 Wheel Variant from WheelNext Summit 2025 @ Meta HQ
19. • Problem Choose appropriate nodes having compatible accelerators for a given workload Need to support multi-node jobs (aka gang scheduling) • Solution: full automation no user intervention at cluster scale Per-node variant provider + Per-workload variant labels + Variant matcher within the scheduler Backend.AI Sokovan Scheduler Workload's variant spec is populated from container image labels (scanned & cached in prior) https://github.com/lablup/backend.ai
20. • Making Docker CLI and container registries to support variants e.g., "docker pull" + Docker Hub & Harbor registry • Auto labeling container images when building/installing Python packages during image builds e.g., Could we make "docker build" to automatically do this? • What would be the additional requirements to wheel variants for use in containers? Further Ideas / Discussions
21. Sharing Malware Scan Results of PyPI from Multiple Providers Daehyun Sung, Joongi Kim @ Lablup Inc.
22. • My company Lablup offers Reservoir , a private mirror service to air gapped AI cluster customers. PyPI, Ubuntu, CentOS, CRAN • According to the security compliances and regulations, we are often requested to have security/malware scanning of the artifacts before delivery. The delivery is usually done via hard-disks brought by our FDE. • Devliery frequency: once per month We are combining access to Korea's local mirrors by Kakao Corp. Our Operation
23. • Size Growth The sheer volume of PyPI artifacts 40 TB in total now (doubled since 2024) https://pypi.org/stats/ We (and our customers) are running out of disks! Current Status: Increasing Size
24. • Monthly malware scanning by Lablup Ahnlab V3 (a Korean antivirus solution) ClamAV • Observation Recent rapid increase of supply chain attacks Recent days: copy-fail, dirty-frag, nginx-rift, ... The same happening in PyPI, too Current Status: Increasing Malware
25. • Registering Lablup as a malware scan result provider...? • Cooldown periods in the PyPI server side or pip client side Core dev, Donghee Na, has applied a custom company-wise cooldown proxy to his company. How to protect other users? Things to consider Structured skipping Urgent redistributions (e.g., responses to CVEs) (Discussed during Mike Fiedler's talk) Towards Trustworthy PyPI
26. • Annotating each package with public scan results e.g., "This package was validated by a scan at 2025-06-01 by one or more scanning providers." Need to discuss/decide which metadata to include. Make it available through index APIs so that automated mirroring tools can decide whether to include/exclude the flagged packages. Example: Google Assured Open Source SW (Java, Python packages) https://cloud.google.com/security/products/assured-open-source-software https://docs.cloud.google.com/security-command-center/docs/aoss-supported-packages- premium How to balance open-source freedom to register new packages vs. providing trustworthy/validated packages? Towards Trustworthy PyPI Mirroring