동기
현재 이 두 개의 Python 휠을 유지 관리하고 있습니다:
이전에는 setup.py를 사용하여 패키징했지만, 11월에 NJUlogin을 업데이트할 때 다음과 같은 알림을 발견했습니다:
그래서 새로운 pyproject.toml 방식을 사용하여 패키징하기로 결정했습니다. 그때 임시로 Poetry를 배워서 NJUlogin에 적용했고, 오늘 mijia-api를 업데이트하면서 겸사겸사 적용하려고 했는데 사용법을 잊어버려서 블로그에 기록해두려고 합니다. 앞으로도 Poetry를 자주 사용하여 의존성을 관리해야겠습니다.
Poetry
Poetry 공식 웹사이트에서 스스로를 다음과 같이 설명합니다: Python packaging and dependency management made easy. 사용법이 npm과 비슷하며(Node.js에 대해 어느 정도 알고 있다면), 명령줄을 통해 의존성 관리 파일을 수정합니다.
하지만 poetry는 너무 길어서, 지금부터 pop이라고 부르겠습니다.
설치
문서를 직접 확인하세요: https://python-poetry.org/docs/#installation
저는 pipx를 사용하여 설치했습니다.
기존 프로젝트 초기화
다음과 같은 pyproject.toml 파일이 생성됩니다.
하지만 제 패키지에 대문자가 포함되어 있어서 [tool.poetry] 아래의 name을 변경하는 동시에, 추가로 수동으로 packages 항목을 추가하고, setup.py의 다른 설정도 추가해야 합니다:
새 Poetry 가상 환경 생성 및 의존성 설치
기본적으로 ~/.cache/pypoetry에 가상 환경이 생성되며, pop config를 사용하여 수정할 수 있습니다. 자세한 내용은 여기 문서를 참조하세요. 저는 개인적으로 프로젝트 디렉터리에 두는 것을 선호합니다:
그런 다음 requirements.txt에서 의존성을 하나씩 설치할 수 있습니다. 아래 명령은 의존성을 pyproject.toml 파일에 기록하고 poetry.lock을 생성합니다:
Poetry의 큰 장점 중 하나는 의존성을 트리 형태로 표시할 수 있다는 점입니다:
이제 원래의 setup.py를 삭제할 수 있습니다.
패키징 및 배포
버전은 poetry-dynamic-versioning을 사용하여 동적으로 지정할 수 있으므로, 매번 pyproject.toml을 수정하여 버전 번호를 지정할 필요가 없습니다.
이제 간단하게 한 줄 명령으로 빌드할 수 있습니다:
twine이 ~/.pypirc를 사용하여 pypi 토큰을 저장하는 것과 달리, Poetry는 추가 설정이 필요합니다:
그런 다음 배포할 수 있습니다!