반응형
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이전에는 다음과 같은 파일들을 따로 관리했습니다...
안녕하세요, 여러분! 벌써 2024년 크리스마스 시즌이 다가오고 있네요. 올해는 아이들과 함께 시애틀에서 특별한 추억을 만들어보는 건 어떨까요? 에메랄드 시티의 겨울은 그 어느 때보다 반짝이고 따뜻합니다. 아이들의 눈높이에 맞춘 즐거운 체험부터 온 가족이 함께 즐길 수 있는 화려한 축제까지, 시애틀의 크리스마스를 더욱 특별하게 만들어줄 이벤트들을 자세히 살펴보겠습니다.빛으로 물든 시애틀의 밤1. Enchant Christmas at T-Mobile ParkT-Mobile Park가 마법의 성으로 변신합니다! 11월 22일부터 12월 29일까지 열리는 이 행사는 세계 최대 규모의 크리스마스 조명 미로를 자랑합니다. 아이들과 함께 미로를 탐험하며 숨겨진 보물을 찾아보세요.미로 외에도 아이스 스케이팅 트레일,..
이 시리즈를 통해 파이썬 코드를 더 현대적이고 효율적인 방식으로 작성하기 위한 다양한 기법을 알아보았습니다. 오래된 문법이나 관용구 대신, Python 3.6+ 이후에 등장한 새로운 문법과 라이브러리를 적극 활용하면 코드 가독성, 유지보수성, 성능 및 생산성 측면에서 큰 이점을 얻을 수 있습니다.이번 글에서는 지금까지 다룬 내용을 간략히 정리하고, 실제 프로젝트 적용을 위한 주의점과 추가로 탐색할 만한 주제를 제시하겠습니다.지금까지 다룬 내용 정리f-string (1편):%, str.format() 대비 f-string으로 가독성↑, 변수 참조 직관적, 성능 이점도 기대타입 힌트 & Mypy (2편):타입 힌트로 코드 명확성 증가, 대규모 프로젝트 유지보수성↑Mypy 정적 분석으로 런타임 전 타입 오류 ..
파이썬은 예전부터 간단한 리스트 컴프리헨션, map(), filter() 함수로 함수형 프로그래밍(FP) 스타일을 지원했습니다. 하지만 복잡한 데이터 처리 로직을 구현할 때는 여전히 for 루프가 길어지거나, 중간 중간 임시 변수를 많이 선언하는 경우가 발생할 수 있었습니다.functools, itertools 모듈은 이러한 문제를 해결하기 위한 고급 함수형 툴셋을 제공하여, 데이터 변환, 그룹화, 누적 연산 등을 더 직관적이고 Pythonic하게 처리할 수 있게 합니다.이번 글에서는 기존 방식과 새로운 함수형 접근법의 비교, 주요 함수 및 장단점을 살펴봅니다.이전에는 어떻게 했을까?전통적 for 루프 기반 처리data = [1, 2, 3, 4, 5]# 짝수만 제곱해서 합산하기result = 0for x..
기존 파이썬 코드에서는 파일, 네트워크 소켓, DB 커넥션 등 자원 사용 후 수동으로 정리(닫기)해야 했습니다. 이를 위해 try-finally 블록을 사용했지만, 매번 이런 보일러플레이트를 작성하는 것은 번거롭고, 예외 발생 시 자원 반납 처리 누락 등의 문제가 생기기 쉬웠습니다.Context Manager와 with문을 사용하면 이러한 자원 정리 과정을 자동화하고, 코드 가독성과 안전성을 크게 향상시킬 수 있습니다.이번 글에서는 기존 방식과 새로운 방식의 비교, Context Manager 개념, with문 사용 예제, 장단점을 살펴봅니다.이전에는 어떻게 했을까?try-finally를 통한 수동 자원 정리f = open("data.txt", "r")try: content = f.read()fin..