[Final] PEP 735 - Dependency Groups in pyproject.toml

원문 링크: PEP 735 - Dependency Groups in pyproject.toml

상태: Final 유형: Standards Track 작성일: 20-Nov-2023

PEP 735 – pyproject.toml 내 의존성 그룹 (Dependency Groups)

상태: Final (최종) 유형: Standards Track (표준 추적) 주제: Packaging (패키징) 생성일: 2023년 11월 20일 해결일: 2024년 10월 10일

중요 사항: 이 PEP는 역사적 문서입니다. 최신 규격인 Dependency Groups는 PyPA specs 페이지에서 유지 관리됩니다.

초록 (Abstract)

이 PEP는 프로젝트의 빌드된 배포판에 포함되지 않는 방식으로 pyproject.toml 파일에 패키지 요구사항을 저장하는 메커니즘을 명시합니다. 이는 requirements.txt 파일과 유사하게, 런처(launcher), IDE 및 기타 도구가 이름으로 찾아 식별할 수 있는 명명된 의존성 그룹을 생성하는 데 적합합니다. 여기서 정의된 기능은 “의존성 그룹(Dependency Groups)”이라고 불립니다.

동기 (Motivation)

파이썬 커뮤니티에는 표준화된 답변이 없는 두 가지 주요 사용 사례가 있습니다.

  1. 패키지의 개발 의존성을 어떻게 정의해야 하는가?
  2. 배포판을 빌드하지 않는 프로젝트(비-패키지 프로젝트)의 의존성을 어떻게 정의해야 하는가?

이 두 가지 요구사항을 지원하기 위해 이 제안과 유사한 두 가지 일반적인 해결책이 있습니다.

  • requirements.txt 파일
  • extras

requirements.txt 파일과 extras 모두 이 표준이 극복하고자 하는 한계를 가지고 있습니다.

이 PEP가 지원하고자 하는 두 가지 다른 유형의 프로젝트는 다음과 같습니다.

  • 라이브러리와 같은 파이썬 패키지
  • 데이터 과학 프로젝트와 같은 비-패키지 프로젝트

requirements.txt 파일의 한계

많은 프로젝트가 하나 이상의 requirements.txt 파일을 정의할 수 있으며, 프로젝트 루트(예: requirements.txt 및 test-requirements.txt) 또는 디렉토리(예: requirements/base.txt 및 requirements/test.txt)에 배치할 수 있습니다. 그러나 이러한 방식으로 요구사항 파일을 사용하는 데에는 주요 문제가 있습니다.

  • 도구가 이러한 파일을 이름으로 검색하거나 사용할 수 있는 표준화된 명명 규칙이 없습니다.
  • requirements.txt 파일은 표준화되어 있지 않고, 대신 pip에 옵션을 제공합니다.
    • 결과적으로 requirements.txt 파일을 기반으로 도구 동작을 정의하기 어렵습니다.
    • 이름으로 발견하거나 식별하기가 쉽지 않으며, 그 내용은 패키지 지정자(package specifiers)와 추가 pip 옵션이 혼합되어 있을 수 있습니다.
    • requirements.txt 내용에 대한 표준의 부재는 pip 이외의 다른 도구에서 처리할 때 이식성이 없다는 것을 의미하기도 합니다.
  • 또한, requirements.txt 파일은 의존성 목록당 하나의 파일을 필요로 합니다. 특정 사용 사례의 경우, 이는 의존성 그룹화의 한계 비용을 이점과 비교하여 높게 만듭니다. 여러 개의 작은 의존성 그룹을 가진 프로젝트에는 더 간결한 선언이 유용합니다.

이와 대조적으로, 의존성 그룹(Dependency Groups)은 pyproject.toml의 잘 알려진 위치에 완전히 표준화된 내용으로 정의됩니다.

extras의 한계

extras는 [project.optional-dependencies] 테이블에 선언된 추가 패키지 메타데이터입니다. 이는 패키지의 메타데이터의 일부로 게시되는 패키지 지정자 목록에 이름을 제공하며, 사용자는 pip install 'foo[bar]'와 같이 해당 이름으로 요청하여 foo를 bar extra와 함께 설치할 수 있습니다.

extras는 패키지 메타데이터이므로 정적으로 정의된다는 보장이 없으며 해결하기 위해 빌드 시스템이 필요할 수 있습니다. 또한, [project.optional-dependencies]의 정의는 많은 도구에 프로젝트가 패키지임을 나타내며, [project] 테이블의 유효성 검사와 같은 도구 동작을 유도할 수 있습니다.

패키지인 프로젝트의 경우, extras는 개발 의존성을 정의하는 일반적인 해결책이지만, 이러한 상황에서도 단점이 있습니다.

  • extra는 선택적 추가 의존성을 정의하므로, 현재 패키지 및 그 의존성을 설치하지 않고 extra를 설치하는 것은 불가능합니다.
  • 사용자가 설치할 수 있기 때문에 extras는 패키지의 공개 인터페이스의 일부입니다.
  • extras가 게시되므로, 패키지 개발자는 개발 extras가 사용자 대면 extras와 혼동되지 않도록 보장하는 데 종종 신경을 씁니다.

근거 (Rationale)

이 PEP는 [dependency-groups] 테이블 내의 목록에 요구사항 데이터를 저장하는 것을 정의합니다. 이 이름은 기능의 표준 이름(“Dependency Groups”)과 일치하도록 선택되었습니다.

이 형식은 많은 경우에 기존 requirements.txt 파일과 매우 유사한 형식을 가지며 가능한 한 간단하고 배우기 쉬워야 합니다. [dependency-groups]의 각 목록은 패키지 지정자 목록으로 정의됩니다. 예를 들어:

[dependency-groups]
test = ["pytest>7", "coverage"]

requirements.txt 파일에는 PEP 508 의존성 지정자(dependency specifiers)로 표현할 수 없는 데이터를 요구하는 여러 사용 사례가 있습니다. 이러한 필드는 의존성 그룹(Dependency Groups)에서는 유효하지 않습니다. 인덱스 서버, 해시, 경로 의존성 등 pip이 지원하는 많은 데이터와 필드를 포함하려면 새로운 표준이 필요합니다. 이 표준은 새로운 표준 및 개발을 위한 여지를 남겨두지만, 모든 유효한 requirements.txt 내용을 지원하려고 시도하지는 않습니다.

유일한 예외는 requirements.txt 파일이 다른 파일을 포함하는 데 사용하는 -r 플래그입니다. 의존성 그룹은 유사한 의미의 “include” 메커니즘을 지원하여 하나의 의존성 그룹이 다른 그룹을 확장할 수 있도록 합니다.

의존성 그룹에는 requirements.txt 파일과 유사한 두 가지 추가 기능이 있습니다.

  • 빌드된 배포판에 별도의 메타데이터로 게시되지 않습니다.
  • 의존성 그룹을 설치한다고 해서 패키지의 의존성이나 패키지 자체의 설치가 암시되지는 않습니다.

사용 사례 (Use Cases)

이 PEP의 중요한 목표로 간주되는 다음 사용 사례가 있습니다. 이는 “부록 C: 사용 사례(Appendix C: Use Cases)”에 자세히 정의되어 있습니다.

  • 파이썬 패키징 빌드 프로세스를 거치지 않고 배포되는 웹 애플리케이션
  • 게시되지 않은 개발 의존성 그룹을 가진 라이브러리
  • 의존성 그룹은 있지만 핵심 패키지가 없는 데이터 과학 프로젝트
  • 락 파일(lockfile) 생성에 대한 입력 데이터 (의존성 그룹은 일반적으로 잠긴 의존성 데이터를 위한 위치로 사용되어서는 안 됩니다.)
  • tox, Nox, Hatch와 같은 환경 관리자(environment manager)에 대한 입력 데이터
  • 테스트 및 린터(linter) 요구사항의 구성 가능한 IDE 검색

Poetry 및 PDM 의존성 그룹 관련

기존의 Poetry 및 PDM 도구는 각각 “Dependency Groups”라고 부르는 기능을 이미 제공합니다. 그러나 의존성 컬렉션을 지정하기 위한 표준이 없기 때문에 각 도구는 [tool] 테이블의 관련 섹션에서 도구별 방식으로 이를 정의합니다. (PDM은 일부 의존성 그룹에 extras도 사용하며 extras 개념과 많이 겹칩니다.)

이 PEP는 Poetry 및 PDM의 모든 기능을 지원하지 않습니다. 이러한 도구는 pip의 requirements.txt 파일과 마찬가지로 일반적인 의존성 지정자에 대한 여러 비표준 확장을 지원합니다.

이러한 도구는 표준화된 의존성 그룹을 자체 의존성 그룹 메커니즘의 확장으로 사용할 수 있어야 합니다. 그러나 기존 Poetry 및 PDM 솔루션을 대체하는 새로운 데이터 형식을 정의하는 것은 목표가 아닙니다. 그렇게 하려면 이러한 도구에서 지원하는 경로 의존성(path dependencies)과 같은 몇 가지 추가 기능을 표준화해야 합니다.

의존성 그룹은 숨겨진 Extras가 아닙니다.

의존성 그룹은 게시되지 않는 extras와 매우 유사합니다. 그러나 extras와는 다음과 같은 두 가지 주요 기능으로 구별됩니다.

  • 비-패키지 프로젝트를 지원합니다.
  • 의존성 그룹을 설치한다고 해서 패키지의 의존성(또는 패키지 자체) 설치가 암시되지는 않습니다.

명세 (Specification)

이 PEP는 pyproject.toml 파일에 dependency-groups라는 새 섹션(테이블)을 정의합니다. dependency-groups 테이블은 임의의 수의 사용자 정의 키를 포함하며, 각 키의 값은 요구사항(아래 정의됨) 목록입니다. 이 키는 유효한 비정규화된 이름이어야 하며, 비교하기 전에 정규화되어야 합니다.

도구는 기본적으로 원래의 비정규화된 이름을 사용자에게 제공하는 것을 선호해야 합니다. 정규화 후 중복된 이름이 발견되면, 도구는 오류를 발생시켜야 합니다.

dependency-groups 아래의 요구사항 목록은 문자열, 테이블(파이썬에서는 “dict”), 또는 문자열과 테이블의 혼합을 포함할 수 있습니다.

  • 요구사항 목록의 문자열은 PEP 508에 정의된 유효한 의존성 지정자(Dependency Specifiers)여야 합니다.
  • 요구사항 목록의 테이블은 유효한 의존성 객체 지정자(Dependency Object Specifiers)여야 합니다.

의존성 객체 지정자 (Dependency Object Specifiers)

의존성 객체 지정자는 0개 이상의 의존성을 정의하는 테이블입니다. 이 PEP는 단 한 가지 유형의 의존성 객체 지정자인 “의존성 그룹 포함(Dependency Group Include)”만을 표준화합니다. 다른 유형은 향후 표준에서 추가될 수 있습니다.

의존성 그룹 포함 (Dependency Group Include)

의존성 그룹 포함은 다른 의존성 그룹의 의존성을 현재 의존성 그룹에 포함합니다. 포함은 정확히 하나의 키 "include-group"을 가진 테이블로 정의되며, 그 값은 다른 의존성 그룹의 이름인 문자열입니다.

예를 들어, {include-group = "test"}는 test 의존성 그룹의 내용을 확장하는 포함입니다.

포함은 명명된 의존성 그룹의 내용과 정확히 동일하게 정의되며, 포함 위치에 현재 그룹에 삽입됩니다. 예를 들어, foo = ["a", "b"]가 하나의 그룹이고 bar = ["c", {include-group = "foo"}, "d"]가 다른 그룹이라면, 의존성 그룹 포함이 확장될 때 bar는 ["c", "a", "b", "d"]로 평가되어야 합니다.

의존성 그룹 포함은 동일한 패키지를 여러 번 지정할 수 있습니다. 도구는 포함에 의해 생성된 목록 내용을 중복 제거하거나 다른 방식으로 변경해서는 안 됩니다.

의존성 그룹 포함은 의존성 그룹 포함을 포함하는 목록을 포함할 수 있으며, 이 경우 해당 포함도 확장되어야 합니다. 의존성 그룹 포함은 순환(cycle)을 포함해서는 안 되며, 도구는 순환을 감지하면 오류를 보고해야 합니다.

예시 의존성 그룹 테이블 (Example Dependency Groups Table)

다음은 네 개의 의존성 그룹(test, docs, typing, typing-test)을 정의하기 위해 이를 사용하는 부분적인 pyproject.toml의 예시입니다.

[dependency-groups]
test = ["pytest", "coverage"]
docs = ["sphinx", "sphinx-rtd-theme"]
typing = ["mypy", "types-requests"]
typing-test = [{include-group = "typing"}, {include-group = "test"}, "useful-types"]

이러한 의존성 그룹 선언 중 어떤 것도 현재 패키지, 그 의존성 또는 선택적 의존성을 암시적으로 설치하지 않습니다. test와 같은 의존성 그룹을 사용하여 패키지를 테스트하려면 사용자 구성 또는 도구 체인도 현재 패키(. )를 설치해야 합니다.

패키지 빌딩 (Package Building)

빌드 백엔드(build backends)는 빌드된 배포판에 의존성 그룹 데이터를 패키지 메타데이터로 포함해서는 안 됩니다. 이는 sdists의 PKG-INFO 및 wheels의 METADATA에 의존성 그룹을 포함하는 참조 가능한 필드가 없음을 의미합니다.

동적 메타데이터 평가에 의존성 그룹을 사용하는 것은 유효하며, sdists에 포함된 pyproject.toml 파일은 자연스럽게 [dependency-groups] 테이블을 계속 포함할 것입니다. 그러나 테이블 내용은 게시된 패키지의 인터페이스의 일부가 아닙니다.

의존성 그룹 설치 (Installing Dependency Groups)

의존성 그룹을 지원하는 도구는 사용자가 의존성 그룹에서 설치할 수 있도록 새로운 옵션과 인터페이스를 제공할 것으로 예상됩니다.

패키지의 의존성 그룹을 표현하기 위한 구문은 두 가지 이유로 정의되지 않습니다.

  1. PyPI에서 타사 패키지의 의존성 그룹을 참조하는 것은 유효하지 않습니다(데이터가 게시되지 않도록 정의되어 있기 때문입니다).
  2. 의존성 그룹에 대한 현재 패키지가 보장되지 않습니다 – 그 목적 중 일부는 비-패키지 프로젝트를 지원하는 것입니다.

예를 들어, 의존성 그룹을 설치하기 위한 가능한 pip 인터페이스는 다음과 같습니다.

pip install --dependency-groups=test,typing

이것은 예시일 뿐입니다. 이 PEP는 도구가 의존성 그룹 설치를 어떻게 지원해야 하는지에 대한 요구사항을 선언하지 않습니다.

어떻게 가르칠 것인가 (How to Teach This)

이 기능은 표준 이름인 “의존성 그룹(Dependency Groups)”으로 불려야 합니다.

기본적인 사용 형태는 일반적인 requirements.txt 데이터의 변형으로 가르쳐져야 합니다. 표준 의존성 지정자(PEP 508)는 명명된 목록에 추가될 수 있습니다. pip에게 requirements.txt 파일에서 설치하도록 요청하는 대신, pip 또는 관련 워크플로우 도구가 명명된 의존성 그룹에서 설치할 것입니다.

새로운 파이썬 사용자에게는 현재 requirements.txt 파일을 사용하는 방법을 배우는 것과 유사하게, pyproject.toml에 의존성 그룹을 포함하는 섹션을 직접 생성하도록 가르칠 수 있습니다. 이는 또한 새로운 파이썬 사용자가 패키지 빌딩에 대해 배울 필요 없이 pyproject.toml 파일에 대해 배울 수 있도록 합니다. [dependency-groups]만 있고 다른 테이블이 없는 pyproject.toml 파일도 유효합니다.

새로운 사용자와 숙련된 사용자 모두에게 의존성 그룹 포함(Dependency Group Includes)을 설명해야 합니다. requirements.txt 사용 경험이 있는 사용자에게는 -r의 유사체로 설명할 수 있습니다. 새로운 사용자에게는 포함이 하나의 의존성 그룹이 다른 그룹을 확장할 수 있도록 한다고 가르쳐야 합니다. 유사한 구성 인터페이스와 파이썬 list.extend 메서드를 비유로 사용하여 아이디어를 설명할 수 있습니다.

거부된 아이디어 (Rejected Ideas)

각 의존성 그룹을 테이블로 정의하지 않는 이유

각 의존성 그룹을 하위 테이블로 정의하여 각 그룹에 향후 키를 연결할 수 있도록 하는 것이 미래 확장성을 위한 가장 큰 유연성을 제공합니다. 그러나 이는 구조를 더 깊게 중첩시켜 가르치고 배우기 어렵게 만듭니다. 이 PEP의 목표 중 하나는 많은 requirements.txt 사용 사례에 대한 쉬운 대체제가 되는 것입니다.

PEP 508 외의 더 많은 의존성 지정자를 허용하지 않는 이유

논의 중에 PEP 508로 가능한 것보다 더 표현적인 지정자가 필요한 여러 사용 사례가 있었습니다. 특히 로컬 경로를 참조하는 “경로 의존성(Path Dependencies)”과 [project.dependencies]에 대한 참조가 특히 관심사였습니다.

그러나 이러한 기능에 대한 기존 표준이 없습니다(pip의 구현 세부 사항이라는 사실상의 표준 제외). 결과적으로, 이러한 기능을 이 PEP에 포함하려고 시도하면 이러한 다양한 기능과 pip 동작을 표준화하려는 시도로 인해 범위가 상당히 확대됩니다.

지연된 아이디어 (Deferred Ideas)

[project.dependencies] 또는 [project.optional-dependencies]에서 의존성 그룹 포함을 지원하지 않는 이유

이 명세의 초기 초안은 [project] 테이블에서 의존성 그룹 포함을 사용할 수 있도록 허용했습니다. 그러나 커뮤니티 피드백 중에 제거로 이어진 여러 문제가 제기되었습니다.

의존성 그룹을 포함함으로써 해결될 추가 사용 사례는 소수에 불과했으며, 명세의 범위를 상당히 증가시켰습니다. 특히, 이러한 포함은 추가로 인해 영향을 받는 당사자의 수를 증가시킬 것입니다. 빌드 백엔드, SBOM 생성기 및 의존성 분석기를 포함하여 [project] 테이블을 읽는 많은 주체는 [project] 변경으로 인해 영향을 받지만, 새로운 (그러나 연결되지 않은) [dependency-groups] 테이블이 있는 경우 현재 상태로 계속 작동할 수 있습니다.

위의 우려와는 별개로, [project] 테이블에서 의존성 그룹의 포함을 허용하면 패키지 관리자가 의존성 메타데이터를 현재 표준 위치 밖으로 이동하도록 장려하게 됩니다. 이는 정적 pyproject.toml 메타데이터를 복잡하게 만들고 의존성 메타데이터를 한 곳에 저장하려는 PEP 621의 목표와 충돌합니다.

마지막으로, 이 PEP에서 [project] 지원을 제외하는 것은 최종적인 것이 아닙니다. 해당 테이블에서 포함을 사용하거나 [dependency-groups]에서 [project]로의 포함 구문은 향후 PEP에 의해 도입되어 자체적인 장점으로 고려될 수 있습니다.

부록 C: 사용 사례 (Appendix C: Use Cases)

웹 애플리케이션 (Web Applications)

웹 애플리케이션(예: Django 또는 Flask 앱)은 종종 배포판을 빌드할 필요가 없지만, 소스를 배포 도구 체인에 번들링하여 제공합니다. 이러한 애플리케이션은 빌드뿐만 아니라 린팅, 테스트 등을 위한 의존성 그룹을 가집니다. 오늘날 이러한 애플리케이션은 종종 패키징 도구와 extras와 같은 메커니즘을 사용하여 의존성 그룹을 관리하기 위해 자신을 패키지로 정의합니다. 그러나 개념적으로는 sdist 또는 wheel 형식으로 배포하기 위한 패키지가 아닙니다.

의존성 그룹은 이러한 애플리케이션이 패키징 메타데이터에 의존하거나 패키징 용어로 요구 사항을 표현하려고 하지 않고도 다양한 의존성을 정의할 수 있도록 합니다.

라이브러리 (Libraries)

라이브러리는 배포판(sdist 및 wheel)을 빌드하고 PyPI에 게시하는 파이썬 패키지입니다. 라이브러리의 경우, 의존성 그룹은 개발 의존성 그룹을 정의하기 위한 extras의 대안을 나타내며, 위에서 언급한 중요한 장점이 있습니다.

라이브러리는 테스트 및 타입 확인을 허용하는 test 및 typing 그룹을 정의할 수 있으며, 따라서 라이브러리 자체의 의존성( [project.dependencies]에 지정된 대로)에 의존합니다.

다른 개발 요구 사항은 패키지 설치를 전혀 요구하지 않을 수도 있습니다. 예를 들어, lint 의존성 그룹은 라이브러리 없이도 유효하고 더 빠르게 설치될 수 있습니다.

데이터 과학 프로젝트 (Data Science Projects)

데이터 과학 프로젝트는 일반적으로 공통 도구 체인을 사용하여 데이터를 처리하고 분석하기 위한 스크립트 및 유틸리티의 논리적 컬렉션 형태로 구성됩니다. 구성 요소는 Jupyter Notebook 형식(ipynb)으로 정의될 수 있지만, 동일한 공통 핵심 유틸리티 세트에 의존합니다.

이러한 프로젝트에서는 빌드하거나 설치할 패키지가 없습니다. 따라서 pyproject.toml은 현재 의존성 관리 또는 선언에 대한 해결책을 제공하지 않습니다.

이러한 프로젝트의 경우 적어도 하나의 주요 의존성 그룹을 정의할 수 있는 것이 중요합니다. 예를 들어:

[dependency-groups]
main = ["numpy", "pandas", "matplotlib"]

그러나 다양한 스크립트에 추가 지원 도구가 필요할 수도 있습니다. 프로젝트는 시간이 지남에 따라 다른 구성 요소에 대해 충돌하거나 호환되지 않는 도구 또는 도구 버전을 가질 수도 있습니다.

다음과 같은 보다 정교한 구성을 고려해 보십시오.

[dependency-groups]
main = ["numpy", "pandas", "matplotlib"]
scikit = [{include-group = "main"}, "scikit-learn==1.3.2"]
scikit-old = [{include-group = "main"}, "scikit-learn==0.24.2"]

이는 scikit과 scikit-old를 공통 의존성 모음의 두 가지 유사한 변형으로 정의하며, 다른 스크립트에 맞게 scikit-learn의 다른 버전을 가져옵니다.

락 파일 생성 (Lockfile Generation)

오늘날 파이썬 생태계에는 락 파일을 생성하는 여러 도구가 있습니다. PDM과 Poetry는 각각 자체 락 파일 형식을 사용하며, pip-tools는 버전 핀과 해시를 포함하는 requirements.txt 파일을 생성합니다.

의존성 그룹은 필요한 많은 기능이 부족하므로 락 파일을 저장하기에 적절한 장소가 아닙니다. 가장 중요한 것은 대부분의 락 파일 사용자가 필수적이라고 생각하는 해시를 저장할 수 없다는 것입니다.

그러나 의존성 그룹은 락 파일을 생성하는 도구에 대한 유효한 입력입니다. 또한 PDM과 Poetry는 모두 (자체 의존성 그룹 개념에 따라) 의존성 그룹 이름을 사용하여 해당 그룹의 잠긴 변형을 참조할 수 있도록 합니다.

환경 관리자 입력 (Environment Manager Inputs)

tox, Nox, Hatch에서 흔히 사용되는 방식은 테스트 환경에 일련의 의존성을 설치하는 것입니다.

예를 들어, tox.ini 아래에 타입 확인 의존성이 인라인으로 정의될 수 있습니다.

[testenv:typing]
deps = pyright
       useful-types
commands = pyright src/

이 조합은 제한된 컨텍스트 내에서 바람직한 개발자 경험을 제공합니다. 관련 환경 관리자 아래에서, 테스트 환경에 필요한 의존성은 해당 의존성이 필요한 명령과 함께 선언됩니다. 이는 extras처럼 패키지 메타데이터에 게시되지 않으며, 관련 환경을 구축하는 데 필요한 도구에 의해 검색 가능합니다.

의존성 그룹은 이러한 요구사항 데이터를 도구별 위치에서 더 광범위하게 사용할 수 있는 위치로 효과적으로 “끌어올림”으로써 이러한 용도에 적용됩니다.

IDE 및 편집기의 요구사항 데이터 사용 (IDE and Editor Use of Requirements Data)

IDE 및 편집기 통합은 통합에 사용되는 의존성 그룹에 대한 관례적이거나 구성 가능한 이름 정의의 이점을 누릴 수 있습니다.

편집기 또는 IDE가 프로젝트의 게시되지 않은 의존성을 검색할 수 있는 것이 유용한 두 가지 알려진 시나리오가 있습니다.

  • 테스트: VS Code와 같은 IDE는 특정 테스트를 실행하기 위한 GUI 인터페이스를 지원합니다.
  • 린팅: 편집기 및 IDE는 종종 오류를 강조 표시하거나 자동 수정하는 린팅 및 자동 서식 통합을 지원합니다.

이러한 경우는 test, lint, fix와 같은 관례적인 그룹 이름을 정의하거나 의존성 그룹을 선택할 수 있는 구성 메커니즘을 정의하여 처리할 수 있습니다.

예를 들어, 다음 pyproject.toml은 앞서 언급한 세 그룹을 선언합니다.

[dependency-groups]
test = ["pytest", "pytest-timeout"]
lint = ["flake8", "mypy"]
fix = ["black", "isort", "pyupgrade"]

이 PEP는 이러한 이름을 표준화하거나 이러한 용도로 예약하려고 시도하지 않습니다. IDE는 다양한 목적에 사용되는 그룹 이름을 표준화하거나 사용자가 구성할 수 있도록 허용할 수 있습니다.

이 선언은 프로젝트에 적합한 도구에 대한 프로젝트 작성자의 지식을 해당 프로젝트의 모든 편집자와 공유할 수 있도록 합니다.

⚠️ 알림: 이 문서는 AI를 활용하여 번역되었으며, 기술적 정확성을 보장하지 않습니다. 정확한 내용은 반드시 원문을 확인하시기 바랍니다.

Comments