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

번역·라이선스 안내

이 비공식 한국어 번역은 원문 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의 작성자가 따른 설계 지침은 다음과 같습니다.

합리적인 범위에서 pyproject.toml에 core metadata를 최대한 많이 표현할 수 있는 방법을 정의합니다.
나중에 빌드 백엔드를 통해 동적으로 정의하려는 경우를 위한 탈출구를 두고 메타데이터를 정적으로 정의합니다.
적절한 경우 익숙한 이름을 사용하되, 더 현대적인 용어도 기꺼이 사용합니다.
적절한 경우 빌드 백엔드가 메타데이터를 저수준에서 지정하는 방식을 그대로 모방하기보다 TOML 파일 내에서 사용하기 편리하도록 합니다.
메타데이터에 TOML을 사용해 온 패키징 생태계의 다른 빌드 백엔드에서 배웁니다.
더 낮은 수준에서 기존 표준이 없는 사항을 표준화하려고 시도하지 않습니다.
이 PEP를 사용하여 메타데이터를 지정하는 경우 이를 정식 메타데이터로 간주합니다.

사양

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

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

세부 정보

테이블 이름

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

`name`

형식: 문자열
Core metadata: Name (link)
동의어
- Flit: module/dist-name (링크)
- Poetry: name (링크)
- Setuptools: name (링크)

프로젝트의 이름입니다.

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

도구는 내부 일관성을 위해 이 이름을 읽는 즉시 PEP 503에 명시된 대로 정규화하는 것이 좋습니다.

`version`

형식: 문자열
Core metadata: Version (link)
동의어
- Flit: 해당 없음(__version__ 속성에서 읽음) (링크)
- Poetry: version (링크)
- Setuptools: version (링크)

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

사용자는 이미 정규화된 버전을 지정하는 것을 우선하는 것이 좋습니다.

`description`

형식: 문자열
Core metadata: Summary (link)
동의어
- Flit: 해당 없음
- Poetry: description (link)
- Setuptools: description (link)

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

`readme`

형식: 문자열 또는 테이블
Core metadata: Description (link)
동의어
- Flit: description-file (link)
- Poetry: readme (link)
- Setuptools: long_description (link)

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

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

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

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

`requires-python`

형식: 문자열
Core metadata: Requires-Python (link)
동의어
- Flit: requires-python (link)
- Poetry: [tool.poetry.dependencies] 테이블의 python 의존성으로 (link)
- Setuptools: python_requires (link)

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

`license`

형식: 테이블
Core metadata: License (link)
동의어
- Flit: license (link)
- Poetry: license (link)
- Setuptools: license, license_file, license_files (link)

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

license 키에 사용할 수 있는 실용적인 문자열 값은 향후 PEP에서 SPDX 표현식 지원을 지정할 수 있도록 의도적으로 제외되었습니다(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를 채우는 데 데이터를 사용하는 방법은 다음과 같습니다.

name만 제공된 경우, 해당 값은 적절한 Author/Maintainer에 들어갑니다.
email만 제공된 경우, 해당 값은 적절한 Author-email/Maintainer-email에 들어갑니다.
email과 name이 모두 제공된 경우, 해당 값은 적절한 Author-email/Maintainer-email에 들어가며, 형식은 {name} <{email}>입니다(예: email.headerregistry.Address를 사용하는 등 적절한 인용이 적용됩니다).
여러 값은 쉼표로 구분해야 합니다.

`keywords`

형식: 문자열 배열
Core metadata: Keywords (link)
동의어
- Flit: keywords (link)
- Poetry: keywords (link)
- Setuptools: keywords (link)

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

`classifiers`

형식: 문자열 배열
Core metadata: Classifier (link)
동의어
- Flit: classifiers (link)
- Poetry: classifiers (link)
- Setuptools: classifiers (link)

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

`urls`

형식: 키와 값이 문자열인 테이블입니다.
Core metadata: Project-URL (link)
동의어
- Flit: [tool.flit.metadata.urls] 테이블 (link)
- Poetry: [tool.poetry.urls] 테이블 (link)
- Setuptools: project_urls (link)

키가 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]와 동일합니다. 사용자는 중첩된 하위 표를 생성해서는 안 되며, 엔트리 포인트 그룹을 한 단계 깊이로만 유지해야 합니다.

빌드 백엔드는 메타데이터가 [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에서 이는 각 키가 추가 항목을 지정하고 값이 문자열 배열인 테이블입니다. 배열의 문자열은 유효한 PEP 508 문자열이어야 합니다. 키는 core metadata의 Provides-Extra에 유효한 값이어야 합니다. 따라서 배열의 각 값은 일치하는 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"

하위 호환성

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

보안 영향

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

참조 구현

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

기각된 아이디어

기타 테이블 이름

`[build-system]` 아래의 모든 항목

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

`[package]`

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

`[metadata]`

[project]이후의 가장 유력한 후보였지만, 결국 특정 하위 테이블에는 [project]가 더 읽기 좋다는 데 합의했습니다. 예를 들어 [project.urls]와 같습니다.

메타데이터 제공자 지원

처음에는 이 PEP에서 지정하는 정적 메타데이터와 PEP 517에서 지정하는 prepare_metadata_for_build_wheel()사이에 중간 계층을 추가하자는 제안이 있었습니다. 프로젝트가 빌드 백엔드와 메타데이터 사이에 개입하려는 경우 이를 수행할 수 있는 훅을 제공하자는 아이디어였습니다.

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

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

도구가 PEP 503에 지정된 정규화된 이름만 사용하도록 하면 더 간단하겠지만, 이 아이디어는 이 PEP를 사용하도록 전환하는 프로젝트에 피해를 줄 수 있으므로 최종적으로 거부되었습니다.

빌드에 포함할 파일 지정

작성자들은 설계 논의 중 이 PEP가 프로젝트 메타데이터에만 전적으로 집중하고 빌드 메타데이터는 다루지 않아야 한다고 비교적 빠르게 결정했습니다. 따라서 소스 배포 패키지 또는 휠 파일에 어떤 파일이 포함되어야 하는지를 지정하는 것은 이 PEP의 범위를 벗어납니다.

`[project.urls]`테이블의 이름을 `[project.project-urls]`로 지정하기

이 제안은 이에 대응하는 core metadata가 Project-Url이라는 이름을 사용한다는 데서 비롯되었습니다. 하지만 전체 테이블 이름으로 [project]를 선택하고 나자 “project”라는 단어를 중복해서 사용하는 것은 현재의 더 짧은 이름이 더 적합하다는 점을 시사했습니다.

별도의 `url`/`home-page` 필드 사용

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

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

다양한 도구에서 필수 의존성과 개발 의존성이라는 개념이 발전함에 따라, 이러한 개발 도구를 “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이 예외적인 경우로 나타나 현재 이름을 사용하기로 결정했습니다:

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

`maintainers`를 삭제하여 `authors`와 통합합니다

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), 향후 어떤 형태로든 확장 테이블 형식을 사용할 수 없게 됩니다. 또한 빌드 백엔드가 단일 수준이 아니라 전체 테이블 구조를 순회하고 값 유형에 따라 적절하게 오류를 발생시키도록 해야 하므로 작업이 복잡해집니다.

구조화된 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 에서 확인할 수 있습니다.

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