Following system colour scheme Selected dark colour scheme Selected light colour scheme

Python 개선 제안 한국어 번역

PEP 621 – pyproject.toml에 프로젝트 메타데이터 저장하기

Author:
Brett Cannon <brett at python.org>, Dustin Ingram <di at python.org>, Paul Ganssle <paul at ganssle.io>, Pradyun Gedam <pradyunsg at gmail.com>, Sébastien Eustace <sebastien at eustace.io>, Thomas Kluyver <thomas at kluyver.me.uk>, Tzu-ping Chung <uranusjr at gmail.com>
Discussions-To:
Discourse thread
Status:
Final
Type:
Standards Track
Topic:
Packaging
Created:
22-Jun-2020
Post-History:
22-Jun-2020, 18-Oct-2020, 24-Oct-2020, 31-Oct-2020
Resolution:
Discourse message
Table of Contents

번역·라이선스 안내

이 비공식 한국어 번역은 원문 Copyright 절의 Public Domain or CC0-1.0, whichever is more permissive 조건에 따라 제공합니다. 원저자와 공식 원문은 그대로 표시합니다. 수정되지 않은 기준 원문 · 공식 최신판

Important

This PEP is a historical document. The up-to-date, canonical spec, pyproject.toml specification, is maintained on the PyPA specs page.

×

See the PyPA specification update process for how to propose changes.

초록

이 PEP는 패키징 관련 도구가 사용할 수 있도록 프로젝트의 core metadata를 pyproject.toml 파일에 작성하는 방법을 규정합니다.

동기

이 PEP의 핵심 동기는 다음과 같습니다.

  • 속도, 명세의 용이성, 모호함 제거, 그리고 빌드 백엔드가 결정적으로 사용할 수 있도록, 사용자가 코어 메타데이터를 정적으로 지정하도록 권장합니다.
  • 학습과 빌드 백엔드 간 전환을 쉽게 할 수 있도록 특정 도구에 종속되지 않는 메타데이터 지정 방법을 제공합니다
  • 프로젝트 메타데이터의 “지루한 부분”에 대해 빌드 백엔드 간에 더 많은 코드를 공유할 수 있게 합니다

정적 메타데이터의 동기에 대해 구체적으로 말하자면, 이는 한동안 패키징 생태계 전반의 목표였습니다. 따라서 메타데이터를 정적으로 쉽게 지정할 수 있게 하는 것이 중요합니다. 이는 또한 사용자가 정적 메타데이터를 제공하는 쪽으로 기울어야 하므로, 데이터를 동적으로 지정하는 비용을 높이는 것도 허용된다는 뜻입니다.

정적 메타데이터와 동적 메타데이터의 구분을 요구하는 것은 메타데이터가 지정되지 않았을 때의 모호함을 해소하는 데에도 도움이 됩니다. 어떤 메타데이터든 동적일 수도 있다면, 메타데이터가 없는 것이 의도된 것인지 아니면 나중에 제공될 것이기 때문인지 결코 알 수 없습니다. 동적 메타데이터를 지정하도록 요구함으로써, 메타데이터가 지정되지 않았을 때의 의도가 명확해집니다.

이 PEP는 빌드 백엔드가 요구할 수 있는 모든 메타데이터를 표준화하려는 것이 아니라, 여러 프로젝트에 걸쳐 매우 흔하고 정적이며 일관되게 지정될 때 이점을 얻을 수 있는 core metadata 명세가 다루는 메타데이터만 표준화하려고 합니다. 이는 빌드 백엔드가 휠에 포함할 파일을 지정하는 방법과 같은 패턴에 대해 여전히 자유롭게 혁신할 수 있다는 뜻입니다. 또한 사용자와 빌드 백엔드가 이 PEP를 부분적으로 따르지 않기로 선택할 때 사용할 수 있는 탈출구도 포함되어 있습니다(이는 이 PEP를 전혀 따르지 않는 것과는 구별되며, 후자 역시 가능합니다).

이 PEP는 또한 기반이 되는 core metadata를 어떤 식으로든 변경하려는 것이 아닙니다. 그러한 사항은 별도의 PEP에서 다루어야 하며, 그 PEP로 인해 이 PEP가 규정하는 내용이 변경되거나 추가될 수 있습니다.

근거

이 PEP의 저자들이 따른 설계 지침은 다음과 같습니다.

  • 합리적인 범위 내에서 가능한 한 많은 core metadata를 pyproject.toml에 표현하는 방법을 정의합니다
  • 나중에 빌드 백엔드를 통해 메타데이터를 동적으로 정의하려는 사람들을 위한 탈출구를 두고, 메타데이터를 정적으로 정의합니다
  • 타당한 경우에는 익숙한 이름을 사용하되, 더 현대적인 용어를 사용하는 것도 마다하지 않습니다
  • 타당한 경우에는 빌드 백엔드가 저수준에서 메타데이터를 지정하는 방식을 그대로 따르는 대신 TOML 파일 안에서 사용하기 편리하도록 합니다
  • 메타데이터에 TOML을 사용해 온 패키징 생태계의 다른 빌드 백엔드로부터 배웁니다
  • 저수준에서 기존 표준이 없는 것은 표준화하려고 하지 않습니다
  • 이 PEP를 사용하여 메타데이터를 지정하는 경우, 그 메타데이터는 정식(canonical) 메타데이터로 간주됩니다

명세

프로젝트 메타데이터를 지정할 때, 도구는 이 PEP에 명시된 대로 메타데이터를 반드시 준수하고 존중해야 합니다. 메타데이터가 부적절하게 지정된 경우, 도구는 사용자에게 실수를 알리기 위해 반드시 오류를 발생시켜야 합니다.

이 PEP를 사용하여 지정한 데이터는 정본으로 간주됩니다. 도구는 정적으로 지정된 데이터를 제거하거나 추가하거나 변경할 수 없습니다(CANNOT). 필드가 dynamic으로 표시된 경우에만 도구가 “새로운” 값을 제공할 수 있습니다.

세부 사항

테이블 이름

도구는 이 PEP에서 정의한 필드를 [project]라는 이름의 테이블에 지정해야 합니다(MUST). 어떤 도구도 이 PEP나 후속 PEP에서 정의하지 않은 필드를 이 테이블에 추가할 수 없습니다. 자체 설정을 pyproject.toml에 저장하려는 도구는 PEP 518에 정의된 [tool] 테이블을 사용할 수 있습니다. [project] 테이블이 없으면 빌드 백엔드가 모든 필드를 동적으로 제공한다는 것을 암묵적으로 의미합니다.

name

프로젝트의 이름입니다.

도구는 사용자가 이 필드를 정적으로 정의하도록 요구해야 합니다(MUST).

도구는 내부 일관성을 위해 이 이름을 읽는 즉시 PEP 503에 명시된 대로 정규화해야 합니다(SHOULD).

version

PEP 440에서 지원하는 형식의 프로젝트 버전입니다.

사용자는 이미 정규화된 버전을 지정하는 것을 우선해야 합니다(SHOULD).

description

프로젝트의 요약 설명입니다.

readme

프로젝트의 전체 설명(즉, README)입니다.

이 필드는 문자열 또는 테이블을 받습니다. 문자열이면 전체 설명을 담은 텍스트 파일의 상대 경로입니다. 도구는 파일의 인코딩을 UTF-8로 간주해야 합니다(MUST). 파일 경로가 대소문자 구분 없이 .md 접미사로 끝나면, 도구는 콘텐츠 유형을 text/markdown으로 간주해야 합니다(MUST). 파일 경로가 대소문자 구분 없이 .rst로 끝나면, 도구는 콘텐츠 유형을 text/x-rst로 간주해야 합니다(MUST). 도구가 이 PEP에 정의된 것보다 더 많은 확장자를 인식한다면, 이 필드를 dynamic으로 지정하지 않아도 사용자를 위해 콘텐츠 유형을 추론할 수 있습니다(MAY). 콘텐츠 유형이 주어지지 않았고 접미사를 인식할 수 없는 경우에는 모두 도구가 오류를 발생시켜야 합니다(MUST).

readme 필드는 테이블을 받을 수도 있습니다. file 키는 전체 설명을 담은 파일의 상대 경로를 나타내는 문자열 값을 가집니다. text 키는 전체 설명 그 자체인 문자열 값을 가집니다. 이 두 키는 상호 배타적이므로, 메타데이터에 두 키가 모두 지정되면 도구는 오류를 발생시켜야 합니다(MUST).

readme 필드에 지정한 테이블에는 전체 설명의 콘텐츠 유형을 지정하는 문자열을 받는 content-type 필드도 있습니다. 메타데이터가 테이블에 이 필드를 지정하지 않으면 도구는 오류를 발생시켜야 합니다(MUST). 메타데이터가 charset 매개변수를 지정하지 않으면 UTF-8로 간주합니다. 도구는 원한다면 다른 인코딩을 지원할 수 있습니다(MAY). 도구는 core metadata가 지원하는 콘텐츠 유형으로 변환할 수 있는 대체 콘텐츠 유형을 지원할 수 있습니다(MAY). 그 외의 경우, 지원하지 않는 콘텐츠 유형에 대해 도구는 오류를 발생시켜야 합니다(MUST).

requires-python

프로젝트의 Python 버전 요구 사항입니다.

license

이 테이블에는 두 키 중 하나가 들어갈 수 있습니다. file 키의 값은 프로젝트의 라이선스가 담긴 파일의 상대 경로를 나타내는 문자열입니다. 도구는 해당 파일의 인코딩을 반드시 UTF-8로 간주해야 합니다. text 키의 값은 프로젝트의 라이선스를 나타내는 문자열이며, 그 의미는 core metadata의 License 필드와 같습니다. 이 두 키는 상호 배타적이므로, 메타데이터에 두 키가 모두 지정되어 있으면 도구는 반드시 오류를 발생시켜야 합니다.

향후 PEP에서 SPDX 표현식 지원을 명시할 수 있도록 license 키에 쓸 실용적인 문자열 값은 의도적으로 제외했습니다(file이나 text가 어떤 라이선스를 나타내는지 지정하는 모든 종류의 “type” 필드에도 같은 논리가 적용됩니다).

authors/maintainers

  • 형식: 문자열 키와 값으로 이루어진 인라인 테이블의 배열
  • Core metadata: Author/Author-email/Maintainer/Maintainer-email (link)
  • 동의어
    • Flit: author/author-email/maintainer/maintainer-email (link)
    • Poetry: authors/maintainers (link)
    • Setuptools: author/author_email/maintainer/maintainer_email (link)

프로젝트의 “저자”로 간주되는 사람 또는 조직입니다. 정확한 의미는 해석의 여지가 있습니다. 원래 작성자나 주 작성자, 현재 유지 관리자, 또는 패키지 소유자를 나열할 수 있습니다.

“maintainers”(유지 관리자) 필드는 정확한 의미가 해석의 여지가 있다는 점에서 “authors”와 비슷합니다.

이 필드는 name과 email이라는 2개의 키를 가진 테이블의 배열을 받습니다. 두 값은 모두 문자열이어야 합니다. name 값은 반드시 유효한 이메일 이름(즉, RFC 822에서 이메일 앞에 이름으로 넣을 수 있는 것)이어야 하며, 쉼표를 포함해서는 안 됩니다. email 값은 반드시 유효한 이메일 주소여야 합니다. 두 키는 모두 선택 사항입니다.

이 데이터로 core metadata를 채우는 방법은 다음과 같습니다.

  1. name만 제공된 경우, 그 값은 상황에 따라 Author/Maintainer에 들어갑니다.
  2. email만 제공된 경우, 그 값은 상황에 따라 Author-email/Maintainer-email에 들어갑니다.
  3. email과 name이 모두 제공된 경우, 그 값은 상황에 따라 Author-email/Maintainer-email에 {name} <{email}> 형식으로(예를 들어 email.headerregistry.Address를 사용하는 등 적절히 인용 처리하여) 들어갑니다.
  4. 여러 값은 쉼표로 구분해야 합니다.

keywords

프로젝트의 키워드입니다.

classifiers

프로젝트에 적용되는 Trove classifiers입니다.

urls

키는 URL 레이블이고 값은 URL 자체인 URL 테이블입니다.

진입점

  • 형식: 테이블([project.scripts], [project.gui-scripts], [project.entry-points])
  • Core metadata: 해당 없음; Entry points specification
  • 동의어
    • Flit: 콘솔 스크립트에는 [tool.flit.scripts] 테이블, 나머지에는 [tool.flit.entrypoints] (link)
    • Poetry: 콘솔 스크립트에는 [tool.poetry.scripts] 테이블 (link)
    • Setuptools: entry_points (link)

진입점과 관련된 테이블은 세 개입니다. [project.scripts] 테이블은 entry points specification의 console_scripts 그룹에 대응합니다. 테이블의 키는 진입점의 이름이고, 값은 객체 참조입니다.

[project.gui-scripts] 테이블은 entry points specification의 gui_scripts 그룹에 대응합니다. 형식은 [project.scripts]와 같습니다.

[project.entry-points] 테이블은 여러 테이블의 모음입니다. 각 하위 테이블의 이름은 진입점 그룹입니다. 키와 값의 의미는 [project.scripts]와 같습니다. 사용자는 중첩된 하위 테이블을 만들어서는 안 되며(MUST NOT), 대신 진입점 그룹을 한 단계 깊이로만 유지해야 합니다.

메타데이터가 [project.entry-points.console_scripts] 또는 [project.entry-points.gui_scripts] 테이블을 정의하면 빌드 백엔드는 반드시 오류를 발생시켜야 합니다. 이러한 테이블은 각각 [project.scripts] 및 [project.gui-scripts]와 겹쳐 모호해지기 때문입니다.

dependencies/optional-dependencies

  • 형식: PEP 508 문자열의 배열(dependencies) 및 PEP 508 문자열 배열을 값으로 가지는 테이블(optional-dependencies)
  • Core metadata: Requires-Dist 및 Provides-Extra (link, link)
  • 동의어
    • Flit: 필수 의존성에는 requires, 선택적 의존성에는 requires-extra (link)
    • Poetry: 의존성(필수 및 개발용 모두)에는 [tool.poetry.dependencies], 선택적 의존성에는 [tool.poetry.extras] (link)
    • Setuptools: 필수 의존성에는 install_requires, 선택적 의존성에는 extras_require (link)

프로젝트의 (선택적) 의존성입니다.

dependencies는 값이 문자열 배열인 키입니다. 각 문자열은 프로젝트의 의존성 하나를 나타내며, 반드시 유효한 PEP 508 문자열 형식이어야 합니다. 각 문자열은 core metadata의 Requires-Dist 항목에 직접 대응합니다.

optional-dependencies의 경우, 각 키가 엑스트라(extra)를 지정하고 그 값이 문자열 배열인 테이블입니다. 배열의 문자열은 유효한 PEP 508 문자열이어야 합니다. 키는 반드시 Provides-Extra core metadata의 유효한 값이어야 합니다. 따라서 배열의 각 값은 일치하는 Provides-Extra 메타데이터에 대응하는 Requires-Dist 항목이 됩니다.

dynamic

  • 형식: 문자열 배열
  • Core metadata: 해당 없음
  • 동의어 없음

다른 도구가 메타데이터를 동적으로 제공할 수 있도록(또는 제공하도록) 이 PEP에 나열된 필드 중 어떤 필드를 의도적으로 지정하지 않았는지 명시합니다. 이를 통해 나중에 도구로 제공되는 메타데이터와 달리 어떤 메타데이터를 의도적으로 지정하지 않았으며 앞으로도 지정되지 않은 상태로 남을 것으로 예상되는지 명확하게 구분합니다.

  • 빌드 백엔드는 정적으로 지정된 메타데이터(메타데이터가 해당 필드를 dynamic에 나열하지 않았음을 의미합니다)를 반드시 준수해야 합니다.
  • 메타데이터가 dynamic에 name을 지정하면 빌드 백엔드는 반드시 오류를 발생시켜야 합니다.
  • core metadata 명세에서 어떤 필드를 “Required”로 나열한다면, 메타데이터는 반드시 해당 필드를 정적으로 지정하거나 dynamic에 나열해야 합니다(그렇지 않으면 빌드 백엔드는 반드시 오류를 발생시켜야 합니다. 즉, 필수 필드가 [project] 테이블에 어떤 식으로든 나열되지 않는 일은 있을 수 없어야 합니다).
  • core metadata 명세에서 어떤 필드를 “Optional”로 나열한다면, 빌드 백엔드가 나중에 해당 필드의 데이터를 제공할 것으로 예상되는 경우 메타데이터는 그 필드를 dynamic에 나열할 수 있습니다.
  • 메타데이터가 어떤 필드를 정적으로 지정하면서 동시에 dynamic에도 나열하면 빌드 백엔드는 반드시 오류를 발생시켜야 합니다.
  • 메타데이터가 어떤 필드를 dynamic에 나열하지 않으면 빌드 백엔드는 사용자를 대신하여 필요한 메타데이터를 채울 수 없습니다(즉, dynamic은 도구가 메타데이터를 채우도록 허용하는 유일한 방법이며, 사용자가 이러한 채우기를 명시적으로 선택해야 합니다).
  • 메타데이터가 dynamic에 어떤 필드를 지정했지만 빌드 백엔드가 그 필드의 데이터를 제공할 수 없었다면 빌드 백엔드는 반드시 오류를 발생시켜야 합니다.

예시

[project]
name = "spam"
version = "2020.0.0"
description = "Lovely Spam! Wonderful Spam!"
readme = "README.rst"
requires-python = ">=3.8"
license = {file = "LICENSE.txt"}
keywords = ["egg", "bacon", "sausage", "tomatoes", "Lobster Thermidor"]
authors = [
  {email = "hi@pradyunsg.me"},
  {name = "Tzu-ping Chung"}
]
maintainers = [
  {name = "Brett Cannon", email = "brett@python.org"}
]
classifiers = [
  "Development Status :: 4 - Beta",
  "Programming Language :: Python"
]

dependencies = [
  "httpx",
  "gidgethub[httpx]>4.0.0",
  "django>2.1; os_name != 'nt'",
  "django>2.0; os_name == 'nt'"
]

[project.optional-dependencies]
test = [
  "pytest < 5.0.0",
  "pytest-cov[all]"
]

[project.urls]
homepage = "https://example.com"
documentation = "https://readthedocs.org"
repository = "https://github.com"
changelog = "https://github.com/me/spam/blob/master/CHANGELOG.md"

[project.scripts]
spam-cli = "spam:main_cli"

[project.gui-scripts]
spam-gui = "spam:main_gui"

[project.entry-points."spam.magical"]
tomatoes = "spam:main_tomatoes"

하위 호환성

이 PEP는 프로젝트의 core metadata를 지정하는 새로운 방법을 제공하며 PEP 518에서 설명한 예약된 네임스페이스에 속하는 새로운 테이블 이름을 사용하므로 하위 호환성 문제는 없습니다.

보안 영향

이 PEP는 프로젝트 메타데이터를 정적으로 정의하는 방법을 다루므로 직접적인 보안 문제는 없습니다. 보안 문제가 있다면 이는 도구가 메타데이터를 소비하고 그에 따라 동작하기로 선택하는 방식에서 비롯될 것입니다.

참조 구현

현재 이 PEP를 구현한 빌드 백엔드의 개념 증명은 없습니다.

기각된 아이디어

다른 테이블 이름

[build-system] 아래의 모든 것

이 테이블 이름을 사용하면, 예를 들어 [build-system.metadata]를 테이블로 사용하는 경우처럼 빌드 메타데이터와 프로젝트 메타데이터 사이의 혼동이 더 심해질 수 있다는 우려가 있었습니다.

[package]

강력한 지지를 얻지 못했습니다.

[metadata]

[project] 다음으로 가장 유력한 후보였지만, 결국 [project.urls] 같은 일부 하위 테이블에서는 [project]가 더 잘 읽힌다는 데 의견이 모였습니다.

메타데이터 제공자 지원

처음에는 이 PEP가 명시하는 정적 메타데이터와 PEP 517이 명시하는 prepare_metadata_for_build_wheel() 사이에 중간 계층을 추가하자는 제안이 있었습니다. 프로젝트가 빌드 백엔드와 메타데이터 사이에 끼어들고 싶을 때 이를 위한 훅을 제공하자는 것이 그 아이디어였습니다.

결국 저자들은 이 아이디어가 불필요하게 복잡하고, 사람들이 코어 메타데이터를 가능한 한 정적으로 정의하도록 유도한다는 이 PEP의 설계 목표에서 벗어나게 만든다고 판단했습니다.

정규화된 프로젝트 이름 요구하기

도구가 PEP 503에 명시된 정규화된 이름만 다루면 일이 더 쉬워지겠지만, 이 PEP를 사용하도록 전환하는 프로젝트에 불리하다는 이유로 이 아이디어는 결국 기각되었습니다.

빌드 시 포함할 파일 지정하기

저자들은 설계 논의 중에 이 PEP가 빌드 메타데이터가 아닌 프로젝트 메타데이터에만 집중해야 한다고 꽤 빨리 결정했습니다. 따라서 소스 배포판이나 wheel 파일에 어떤 파일이 포함되어야 하는지를 지정하는 것은 이 PEP의 범위를 벗어납니다.

[project.urls] 테이블의 이름을 [project.project-urls]로 짓기

이 제안은 대응하는 core metadata가 Project-Url이라는 점에서 나왔습니다. 하지만 전체 테이블 이름으로 [project]가 선택되고 나자, “project”라는 단어가 중복으로 쓰인다는 점 때문에 현재의 더 짧은 이름이 더 적합하다고 판단되었습니다.

별도의 url/home-page 필드 두기

core metadata가 이를 지원하기는 하지만, 전체 테이블을 지원하면서 프로젝트 URL을 위한 단일 필드도 두는 것은 중복되고 혼란스러워 보였습니다.

도구가 개발 관련 의존성을 “dev” extra에 넣도록 권장하기

여러 도구에서 필수 의존성과 개발 의존성을 구분하는 개념이 생겨나면서, 도구들에게 그러한 개발 도구를 “dev” 그룹에 넣도록 제안하자는 아이디어가 나왔습니다. 하지만 결국 저자들은 그러한 워크플로를 제안하는 것이 이 명세의 범위를 벗어난다고 판단했습니다.

dynamic 필드가 누락된 필수 필드만 명시하도록 요구하기

저자들은 dynamic 필드에 누락된 필수 필드만 나열하도록 요구하고, 선택 필드를 나열하는 것은 선택 사항으로 두는 아이디어를 검토했습니다. 하지만 결국 이는 가능한 한 많은 정보를 정적으로 명시하도록 장려한다는 설계 목표에 어긋났습니다.

readme 필드의 다른 구조

readme 필드에 대해 readme_content_type 필드가 제안되었지만, 저자들은 문자열/테이블 혼합 방식이 더 복잡한 경우도 수용하면서 일반적인 경우에 더 실용적이라고 판단했습니다. long_description과 그에 대응하는 long_description_content_type 필드를 사용하는 것도 마찬가지입니다.

테이블 형식의 file 키는 원래 path로 제안되었지만, file은 setuptools의 file 키에 대응하며, 그 외에는 둘 중 하나를 선택할 뚜렷한 이유가 없습니다.

readme 필드가 text/plain을 암시하도록 허용하기

저자들은 콘텐츠 유형을 지정하지 않으면 text/plain을 기본값으로 하는 방식을 허용하는 것을 검토했지만, PyPI에서 의도치 않게 잘못 렌더링되는 것을 방지하고 사용자가 의도를 분명히 밝히도록 하기 위해 이 경우에는 명시적으로 지정하는 것이 최선이라고 결정했습니다.

dependencies/optional-dependencies의 다른 이름

저자들은 원래 requires/extra-requires를 이름으로 제안했지만, 다른 패키징 생태계를 조사한 결과 Python이 예외적인 경우임이 드러나 현재의 이름을 사용하기로 결정했습니다:

  1. npm
  2. Rust
  3. Dart
  4. Swift
  5. Ruby

현재의 이름으로 통일하면, 새로운 프로그래머에게 반드시 낯설 수밖에 없는 용어를 쓰지 않으면서도 다른 생태계에서 온 사람들의 혼란을 최소화하는 데 도움이 됩니다. 또한 PEP 518에 명시된 [build-system] 테이블의 requires와 혼동할 가능성도 방지합니다.

authors와 통합하기 위해 maintainers 제거

core metadata의 Authors 필드와 Maintainers 필드 간의 차이는 명시되어 있지 않고 모호하므로, 이 PEP는 원래 이 둘을 단일 authors 필드로 통합할 것을 제안했습니다. 다른 생태계에서는 “author”를 사용할 용어로 선택했으므로, 프로젝트를 유지 관리하는 사람들을 나열하는 곳으로 코어 메타데이터의 Author로 표준화하자는 것이 당초의 생각이었습니다.

하지만 결국 일부 코어 메타데이터에 대해 새로운 해석을 도입하려 하기보다는, 코어 메타데이터를 따르기로 하는 결정이 이 PEP의 수용에 도움이 된다는 점에서 더 중요하다고 판단되었습니다.

project.entry-points에 대해 임의 깊이의 테이블 지원

project.entry-points의 하위 테이블 깊이를 1로 유지하면, 점으로 구분된 이름을 사용하면서 따옴표를 쓰는 테이블 이름(예: project.entry-points."spam.magical")에 익숙하지 않은 사용자에게 혼란을 줄 수 있다는 우려가 있었습니다. 그러나 임의의 깊이를 지원하면(예: project.entry-points.spam.magical) 향후 어떠한 형태의 펼친(exploded) 테이블 형식도 사용할 수 없게 됩니다. 또한 빌드 백엔드는 단일 수준이 아니라 전체 테이블 구조를 빠짐없이 순회하고 값의 타입에 따라 적절히 오류를 발생시켜야 하므로, 빌드 백엔드의 작업도 복잡해집니다.

의존성을 지정하기 위해 구조화된 TOML 딕셔너리 사용

프로젝트의 의존성을 지정하는 형식은 데이터 형식 측면에서 가장 뜨거운 논쟁거리였습니다. 이로 인해 PEP 631과 PEP 633이 모두 작성되었으며, 각각 이 PEP에 있는 내용과 TOML 딕셔너리를 더 광범위하게 사용하는 방식을 나타냅니다. 해당 PEP들에 대한 결정은 https://discuss.python.org/t/how-to-specify-dependencies-pep-508-strings-or-a-table-in-toml/5243/38 에서 확인할 수 있습니다.

저자들은 두 형식을 모두 지원하는 방안을 잠시 고려했지만, 사람들이 한 가지 형식이 아니라 두 가지 형식에 익숙해져야 하므로 혼란을 초래할 것이라고 판단했습니다.

sdist를 생성할 때 빌드 백엔드가 pyproject.toml을 갱신하도록 요구

이 PEP가 작성될 당시에는 sdist가 이 PEP처럼 정적이고 표준적인 메타데이터를 갖출 것을 요구하지 않았습니다. 그래서 이 PEP를 그러한 메타데이터를 sdist에 포함시키는 수단으로 사용하자는 아이디어가 검토되었습니다. 하지만 결국 pyproject.toml을 갱신한다는 아이디어는 대체로 호응을 얻지 못했고, 따라서 이 아이디어는 기각되었으며 대신 sdist의 메타데이터 표준화를 별도로 추진하기로 했습니다.

도구가 데이터를 추가/확장하도록 허용

이 PEP의 이전 버전에서는 도구가 필드의 데이터를 확장하는 것이 허용되었습니다. 예를 들어 빌드 백엔드는 버전 번호를 가져와 휠을 빌드할 때 로컬 버전을 덧붙일 수 있었습니다. 도구는 또한 라이선스나 지원되는 Python 버전과 같은 항목에 대해 trove 분류자를 더 추가할 수도 있었습니다.

하지만 결국 처음에는 더 엄격하게 시작하고, 실제 사용 사례를 바탕으로 데이터를 얼마나 정적인 것으로 간주할지 완화하는 방안을 검토하는 편이 더 낫다고 판단되었습니다.

미해결 문제

현재로서는 없습니다.