반응형
많은 Python 프로젝트가 여전히 setup.py, requirements.txt, MANIFEST.in 등 전통적 방식으로 관리되고 있습니다. 이러한 레거시 프로젝트를 모던 Python 패키징 표준인 pyproject.toml 기반으로 마이그레이션하면, 의존성 관리와 빌드/배포 과정이 단순화되고, CI/CD 파이프라인에서 재현성 높은 환경을 손쉽게 구축할 수 있습니다.이번 글에서는 마이그레이션을 위한 단계별 접근 방법, 주의사항, 팀 내 합의 및 베스트 프랙티스 등을 제안합니다.마이그레이션 전략1단계: 기존 의존성, 메타데이터 파악setup.py의 setup() 함수 호출부를 살펴 이름, 버전, author, classifiers 등을 정리requirements.txt에서 런타임/개발 의존성을 분류M..
이번 글에서는 가상의 "my_project"라는 패키지를 예로 들어 pyproject.toml 작성을 단계별로 시연합니다. 목표는 다음과 같습니다.빌드 백엔드: Poetry 선택 (의존성 관리, 빌드, 배포 편의성 활용)기본 메타데이터: 이름, 버전, 저자, 라이선스 등 명시의존성: 런타임 의존성(예: requests), optional-dependencies(dev, docs) 정의스크립트 정의: mytool 명령어 제공린터/포매터 설정: black, mypy 설정 추가 (tool 섹션 활용)프로젝트 디렉토리 구성예제 디렉토리 구조:my_project/ ├─ my_project/ │ ├─ __init__.py │ └─ cli.py ├─ pyproject.toml └─ README.m..
pyproject.toml는 빌드 백엔드 선택에 유연성을 제공합니다. PEP 518 이후 빌드 백엔드를 명시하면 pip나 다른 설치도구가 해당 백엔드를 활용해 프로젝트를 빌드할 수 있습니다. 하지만 빌드 백엔드(예: Flit, Poetry, Hatch, Setuptools)가 각각 고유한 철학과 기능을 갖고 있어, 프로젝트 요구사항에 따라 적절한 백엔드를 선택하는 전략이 필요합니다.이번 글에서는 대표적인 빌드 백엔드를 비교하고, 상황별로 어떤 빌드 백엔드가 적합한지 판단할 수 있는 가이드를 제안합니다.대표적인 빌드 백엔드 소개Setuptools (setuptools.build_meta)가장 오래되고 전통적인 빌드 시스템호환성 광범위, 큰 생태계 지원단점: 설정 방식이 비교적 복잡, 과거 유산(setup...
pyproject.toml의 [build-system] 섹션은 PEP 518에서 정의한 표준으로, 프로젝트를 빌드할 때 필요한 빌드 백엔드와 빌드 단계 의존성을 명확히 지정하는 영역입니다. 이전에는 setup.py를 직접 실행하거나 명령어 옵션을 사용해 빌드 절차를 커스텀했지만, 이로 인해 일관성 없는 빌드 환경 및 복잡한 설정 문제가 있었습니다.[build-system]을 활용하면 빌드 시 필요한 패키지(예: setuptools, wheel)와 빌드 백엔드(예: setuptools.build_meta, Poetry, Flit) 정보를 명료하게 선언하여, pip나 다른 설치 도구가 이를 자동 인식하고 재현성 높은 빌드 절차를 수행합니다.기본 필드[build-system] 섹션은 일반적으로 다음과 같은 필..
예전에는 파이썬 패키지를 만들 때 setup.py, requirements.txt, MANIFEST.in 등 여러 파일을 관리해야 했고, 의존성 관리도 pip와 virtualenv로 수동 처리하곤 했습니다. PEP 518로 제안된 pyproject.toml은 프로젝트 빌드 시스템 표준을 정의하고, Poetry 같은 툴을 이용하면 의존성 관리, 빌드, 배포까지 한 번에 해결할 수 있습니다.이번 글에서는 기존 방식과 새 방식의 비교, pyproject.toml과 Poetry의 장단점, 기본 사용법을 다룹니다.이전에는 어떻게 했을까?setup.py + requirements.txt 방식setup.py로 패키지 메타데이터(이름, 버전, 의존성) 정의requirements.txt로 개발 의존성 관리패키지 빌드/배..