반응형
이 시리즈를 통해 pyproject.toml 파일을 중심으로 한 현대적 파이썬 패키징 표준과 생태계에 대해 폭넓게 다뤄보았습니다. 기존에 setup.py, requirements.txt, MANIFEST.in 등 산재한 설정 파일과 비일관적 빌드 과정에서 벗어나, PEP 518/PEP 621 등 표준에 따라 빌드 백엔드, 메타데이터, 의존성, 스크립트, 도구 설정을 한 곳에서 관리할 수 있음을 확인했습니다.이 마지막 글에서는 지금까지 정리한 내용을 요약하고, 추가로 탐색할 만한 고급 주제와 참고 자료를 제안합니다.시리즈 요약 정리pyproject.toml 등장 배경 및 기본 구조 (1편)과거 패키징 혼란 해결 위해 PEP 518/621 등장, 단일 파일(pyproject.toml)로 설정 통합[build..
많은 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...
기존 파이썬 프로젝트에서는 setup.cfg, .flake8, mypy.ini, tox.ini 등 다양한 도구별 설정 파일이 난립하는 경우가 많았습니다. 하지만 pyproject.toml의 [tool.*] 섹션을 이용하면, 이러한 도구 설정을 한 파일로 모아 프로젝트 구성이 훨씬 단순해집니다.이번 글에서는 [tool] 섹션의 개념과 활용법, Poetry나 Flit, Hatch 등 빌드 백엔드별 설정 예제, 그리고 린터/포매터/테스트 도구 설정을 pyproject.toml에 통합하는 방법을 살펴봅니다.[tool.*] 섹션 개념pyproject.toml는 [tool]이라는 상위 테이블을 제공하며, 하위에 도구명(예: poetry, flit, hatch, black, isort, mypy)을 붙여 [tool...
현대적인 파이썬 프로젝트에서 의존성 관리와 CLI 진입점(엔트리 포인트) 설정은 핵심적인 부분입니다. 이전에는 setup.py나 requirements.txt 등에 의존했지만, 이제 pyproject.toml의 [project] 섹션 내에서 정식 필드를 통해 의존성과 스크립트를 일관적으로 정의할 수 있습니다.이번 글에서는 dependencies, optional-dependencies, scripts 필드를 자세히 살펴보고, 이를 통해 런타임 의존성, 선택적 의존성 그룹, 그리고 명령줄 스크립트를 어떻게 현대적이고 투명하게 관리할 수 있는지 알아봅니다.[project.dependencies]로 런타임 의존성 정의[project] 섹션 내 dependencies 필드는 패키지 런타임에 필요한 필수 의존성을..
PEP 621은 pyproject.toml을 통해 패키지 메타데이터(이름, 버전, 라이선스, 종속성 등)를 표준화하는 제안으로, 이전 setup.py에서 하던 패키지 정보 정의를 더욱 일관되고 선언적인 형태로 바꾸어줍니다. 이를 통해 빌드 백엔드별 메타데이터 정의 방식의 차이를 줄이고, 프로젝트 정보가 한눈에 들어오는 장점을 누릴 수 있습니다.이번 글에서는 [project] 섹션 필드들, PEP 621에서 권장하는 메타데이터 정의 방법, 및 의존성과 optional dependencies 선언 방식 등을 살펴봅니다.[project] 섹션 개요[project] 섹션은 PEP 621에 따라 다음과 같은 패키지 메타데이터 필드를 포함할 수 있습니다.name: 패키지 이름version: 패키지 버전 문자열(PE..
pyproject.toml의 [build-system] 섹션은 PEP 518에서 정의한 표준으로, 프로젝트를 빌드할 때 필요한 빌드 백엔드와 빌드 단계 의존성을 명확히 지정하는 영역입니다. 이전에는 setup.py를 직접 실행하거나 명령어 옵션을 사용해 빌드 절차를 커스텀했지만, 이로 인해 일관성 없는 빌드 환경 및 복잡한 설정 문제가 있었습니다.[build-system]을 활용하면 빌드 시 필요한 패키지(예: setuptools, wheel)와 빌드 백엔드(예: setuptools.build_meta, Poetry, Flit) 정보를 명료하게 선언하여, pip나 다른 설치 도구가 이를 자동 인식하고 재현성 높은 빌드 절차를 수행합니다.기본 필드[build-system] 섹션은 일반적으로 다음과 같은 필..
파이썬 패키징 환경은 오랜 기간 setup.py, requirements.txt 등 여러 파일에 의존해 왔습니다. 이 방식은 비일관적이고, 빌드 백엔드와 의존성 관리가 분산되어 프로젝트 설정이 복잡해지는 문제가 있었습니다. 이러한 문제를 해결하기 위해 PEP 518, PEP 621 등의 표준 제안이 나오고, 그 결과로 pyproject.toml이라는 단일 설정 파일을 중심으로 한 현대적 패키징 생태계가 구축되었습니다.이번 글에서는 pyproject.toml이 왜 등장했는지, 기존 방식 대비 어떤 이점을 갖는지, 그리고 pyproject.toml의 기본 구조를 개괄적으로 살펴보겠습니다.기존 파이썬 패키징 방식: setup.py, requirements.txt이전에는 다음과 같은 파일들을 따로 관리했습니다...
이 시리즈를 통해 파이썬 코드를 더 현대적이고 효율적인 방식으로 작성하기 위한 다양한 기법을 알아보았습니다. 오래된 문법이나 관용구 대신, Python 3.6+ 이후에 등장한 새로운 문법과 라이브러리를 적극 활용하면 코드 가독성, 유지보수성, 성능 및 생산성 측면에서 큰 이점을 얻을 수 있습니다.이번 글에서는 지금까지 다룬 내용을 간략히 정리하고, 실제 프로젝트 적용을 위한 주의점과 추가로 탐색할 만한 주제를 제시하겠습니다.지금까지 다룬 내용 정리f-string (1편):%, str.format() 대비 f-string으로 가독성↑, 변수 참조 직관적, 성능 이점도 기대타입 힌트 & Mypy (2편):타입 힌트로 코드 명확성 증가, 대규모 프로젝트 유지보수성↑Mypy 정적 분석으로 런타임 전 타입 오류 ..