PEP 459 – Python 소프트웨어 패키지를 위한 표준 메타데이터 확장

Author:

Alyssa Coghlan <ncoghlan at gmail.com>

BDFL-Delegate:

Alyssa Coghlan <ncoghlan at gmail.com>

Discussions-To:

Distutils-SIG list

Status:

Withdrawn

Type:

Standards Track

Topic:

Packaging

Requires:

426

Created:

11-Nov-2013

Post-History:

21-Dec-2013

---

Table of Contents

• PEP 철회
• 초록
• 표준 확장 네임스페이스
• python.details 확장
  • 라이선스
  • 키워드
  • Classifiers
  • Document names
• python.project 확장
  • 연락처 정보
  • 연락처
  • 기여자
  • 프로젝트 URL
• python.integrator 확장
• python.exports 확장
  • 내보내기 지정자
  • 모듈
  • 네임스페이스
  • 내보내기
• python.commands 확장
• python.constraints 확장
  • 지원되는 환경
  • 확장 메타데이터 제약 조건
• Copyright

번역·라이선스 안내

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

PEP 철회

이 PEP는 PEP 426에 의존하는데, 해당 PEP 자체가 철회되었습니다. 자세한 내용은 해당 PEP의 PEP 철회 절을 참조하십시오.

그동안 메타데이터 확장은 entry_points.txt 같은 과거 사례에서 그랬던 것처럼 계속 처리됩니다. 즉, 주 METADATA 파일과 함께 메타데이터 디렉터리에 설치되는 추가 파일로 처리됩니다.

초록

이 PEP는 Python 메타데이터에 대한 몇 가지 표준 확장을 설명합니다.

모든 메타데이터 확장과 마찬가지로, 각 표준 확장 형식은 독립적으로 버전이 관리됩니다. 어떤 형식이든 변경하려면 이 PEP를 갱신해야 하지만, 핵심 패키징 메타데이터를 갱신할 필요는 없습니다.

표준 확장 네임스페이스

Python 패키지 색인의 python 프로젝트는 CPython 참조 인터프리터를 가리킵니다. 이 네임스페이스는 표준 메타데이터 확장을 위한 네임스페이스로 사용됩니다.

현재 정의된 표준 확장은 다음과 같습니다:

• python.details
• python.project
• python.integrator
• python.exports
• python.commands
• python.constraints

현재 모든 표준 확장은 버전 1.0이므로, 어떤 기능도 잃지 않고 extension_metadata 필드를 생략할 수 있습니다.

python.details 확장

python.details 확장을 사용하면 소프트웨어 배포판에 관한 더 많은 정보를 제공할 수 있습니다.

python.details 확장에는 네 개의 사용자 정의 하위 필드가 있습니다:

• license: 배포판의 저작권 라이선스
• keywords: 배포판의 패키지 색인 키워드
• classifiers: 배포판의 패키지 색인 Trove 분류자
• document_names: 추가 메타데이터 파일의 이름

이 필드는 모두 선택 사항입니다. 자동화 도구는 배포판이 이 필드들을 제공하지 않더라도 올바르게 동작해야 하며(MUST), 이 필드 중 하나에 의존하는 작업이 요청되면 깔끔하게 실패하는 것도 여기에 포함됩니다.

라이선스

이 배포판에 사용된 라이선스를 요약하는 짧은 문자열입니다.

이 필드를 제공하는 배포판도 해당하는 라이선스 Trove 분류자는 여전히 Classifiers 필드에 명시해야 한다는 점에 유의하십시오. 적절한 Trove 분류자가 있는 경우에도, 라이선스 요약은 해당 라이선스의 특정 버전을 명시하거나 라이선스의 변형 또는 예외 사항을 나타내는 좋은 방법이 될 수 있습니다.

이 필드는 512자 미만이어야 하며(SHOULD), 반드시 2048자 미만이어야 합니다(MUST).

이 필드에는 줄 바꿈이 포함되지 않아야 합니다(SHOULD NOT).

전체 라이선스 텍스트는 배포판의 소스 아카이브에 별도의 파일로 포함되어야 합니다(SHOULD). 자세한 내용은 Document names를 참고하십시오.

예시:

"license": "GPL version 3, excluding DRM provisions"

키워드

더 큰 카탈로그에서 배포판을 검색하는 데 도움이 되도록 사용할 추가 키워드의 목록입니다.

예시:

"keywords": ["comfy", "chair", "cushions", "too silly", "monty python"]

Classifiers

문자열의 목록이며, 각 문자열은 배포판에 대한 하나의 분류 값을 나타냅니다. 분류자는 PEP 301 [2]에 설명되어 있습니다.

예시:

"classifiers": [
  "Development Status :: 4 - Beta",
  "Environment :: Console (Text Based)",
  "License :: OSI Approved :: GNU General Public License v3 (GPLv3)"
]

Document names

배포판의 dist-info 메타데이터 디렉터리에 포함된 보조 문서의 파일 이름입니다.

다음 보조 문서에 이름을 지정할 수 있습니다:

• description: 배포판에 대한 긴 설명이 담긴 파일
• license: 배포판 라이선스의 전체 텍스트가 담긴 파일
• changelog: 배포판에 적용된 변경 사항을 설명하는 파일

보조 문서는 반드시 dist-info 디렉터리에 직접 포함되어야 합니다(MUST). 문서 이름에 디렉터리 구분자를 사용하는 것은 허용되지 않습니다(NOT permitted).

파일의 마크업 형식(있는 경우)은 파일 확장자로 나타냅니다. 이를 통해 색인 서버와 기타 자동화 도구는 의도된 형식을 추측할 필요 없이, 포함된 텍스트 문서를 올바르게 렌더링하고 렌더링 오류에 대한 피드백을 제공할 수 있습니다.

파일 이름에 확장자가 없거나 확장자를 인식할 수 없는 경우, 기본 렌더링 형식은 반드시 일반 텍스트여야 합니다(MUST).

지정된 파일 확장자에는 다음 마크업 렌더러를 사용해야 합니다(SHOULD):

• 일반 텍스트: .txt, 확장자 없음, 알 수 없는 확장자
• reStructured Text: .rst
• Markdown: .md
• AsciiDoc: .adoc, .asc, .asciidoc
• HTML: .html, .htm

자동화 도구는 지정된 형식 중 하나 이상을 일반 텍스트로 렌더링할 수 있으며(MAY), 나열된 형식 외의 다른 마크업 형식도 렌더링할 수 있습니다(MAY).

자동화 도구는 서비스의 무결성을 보호하는 데 필요한 경우를 제외하고는 보조 문서 내용의 최대 길이에 대해 어떠한 가정도 하지 않아야 합니다(SHOULD NOT).

예시:

"document_names": {
    "description": "README.rst",
    "license": "LICENSE.rst",
    "changelog": "NEWS"
}

python.project 확장

python.project 확장을 사용하면 배포 패키지의 생성과 유지 관리에 관한 더 많은 정보를 제공할 수 있습니다.

python.project 확장에는 세 가지 사용자 정의 하위 필드가 있습니다:

• contacts: 배포 패키지의 주요 연락 창구
• contributors: 배포 패키지의 그 밖의 기여자
• project_urls: 배포 패키지와 관련된 URL

연락처 정보

개인과 조직에 관한 세부 정보는 다음 하위 필드를 갖는 매핑으로 기록됩니다:

• name: 개인 또는 그룹의 이름
• email: 이메일 주소(메일링 리스트일 수도 있습니다)
• url: URL(소스 코드 호스팅 서비스의 프로필 페이지 등)
• role: "author", "maintainer", "contributor" 중 하나

name 하위 필드는 필수이며, 나머지 하위 필드는 선택 사항입니다.

특정 역할이 명시되지 않으면 기본값은 contributor입니다.

이메일 주소는 local-part@domain 형식이어야 하며, 이때 local-part는 최대 64자까지 가능하고 이메일 주소 전체는 254자를 넘지 않아야 합니다. 이 형식의 공식 명세는 RFC 5322 (3.2.3절 및 3.4.1절)와 RFC 5321에 있으며, 더 읽기 쉬운 형태는 정보성 문서인 RFC 3696과 관련 정오표에 나와 있습니다.

정의된 기여자 역할은 다음과 같습니다:

• author: 배포 패키지를 처음 만든 사람
• maintainer: 배포 패키지를 처음 만든 사람이 아닌 경우, 해당 배포 패키지의 현재 주 기여자
• contributor: 배포 패키지 생성에 참여한 그 밖의 모든 개인 또는 조직

연락처 및 기여자 메타데이터는 선택 사항입니다. 자동화 도구는 배포 패키지가 이 메타데이터를 제공하지 않더라도 올바르게 동작해야 하며(MUST), 여기에는 이러한 필드 중 하나에 의존하는 작업이 요청되었을 때 깔끔하게 실패하는 것도 포함됩니다.

연락처

프로젝트에 관한 추가 정보를 얻기 위한 권장 연락 창구를 제공하는 기여자 항목의 목록입니다.

아래 예시는 더 큰 개발 그룹의 일원으로 운영되면서 원래 작성자로부터 새로운 수석 유지 관리자에게 인계하는 과정에 있는 프로젝트에 적합합니다.

예시:

"contacts": [
  {
    "name": "Python Packaging Authority/Distutils-SIG",
    "email": "distutils-sig@python.org",
    "url": "https://bitbucket.org/pypa/"
  },
  {
    "name": "Samantha C.",
    "role": "maintainer",
    "email": "dontblameme@example.org"
  },
  {
    "name": "Charlotte C.",
    "role": "author",
    "email": "iambecomingasketchcomedian@example.com"
  }
]

기여자

현재 프로젝트 연락 창구로 아직 기재되지 않은 그 밖의 기여자에 대한 기여자 항목의 목록입니다. 목록 요소 안의 하위 필드는 주 연락처 필드의 하위 필드와 같습니다.

예시:

"contributors": [
  {"name": "John C."},
  {"name": "Erik I."},
  {"name": "Terry G."},
  {"name": "Mike P."},
  {"name": "Graeme C."},
  {"name": "Terry J."}
]

프로젝트 URL

임의의 텍스트 레이블을 프로젝트와 관련된 추가 URL에 대응시키는 매핑입니다.

프로젝트는 자체 레이블과 구체적인 URL을 자유롭게 선택할 수 있지만, 홈페이지, 소스 관리, 이슈 트래커, 문서 링크는 아래 예시의 레이블을 사용하여 제공할 것을 권장합니다(RECOMMENDED).

자동화 도구는 URL 레이블을 대소문자를 구분하지 않는 것으로 취급해야 하지만(MUST), URL 레이블이 유효한 Python 식별자일 필요는 없습니다. 유효한 JSON 문자열이라면 무엇이든 URL 레이블로 사용할 수 있습니다.

예시:

"project_urls": {
  "Documentation": "https://distlib.readthedocs.org",
  "Home": "https://bitbucket.org/pypa/distlib",
  "Repository": "https://bitbucket.org/pypa/distlib/src",
  "Tracker": "https://bitbucket.org/pypa/distlib/issues"
}

python.integrator 확장

구조적으로 이 확장은 python.project 확장과 대부분 동일합니다(확장 이름만 다릅니다).

하지만 project 메타데이터는 소프트웨어의 업스트림 제작자를 가리키는 반면, integrator 메타데이터는 수정된 버전을 재배포하는 다운스트림 재배포자를 가리킵니다.

소프트웨어를 수정하지 않고 재배포하는 경우에는 일반적으로 이 확장을 사용하지 않습니다. 하지만 소프트웨어에 패치를 적용한 경우(예를 들어 이후 버전의 호환 가능한 수정 사항을 백포트하거나 플랫폼 호환성 문제를 해결한 경우)에는 이 확장을 사용해야 하며(SHOULD), 배포판의 버전 식별자에 로컬 버전 레이블을 추가해야 합니다.

재배포 과정에 재배포자가 여럿 있다면, 각 재배포자는 자신의 메타데이터로 이 확장을 덮어쓰기만 하면 됩니다.

python.exports 확장

대부분의 Python 배포판은 Python 모듈 네임스페이스를 통해 임포트할 수 있는 패키지와 모듈을 노출합니다. 배포판은 설치되었을 때 다른 인터페이스를 노출할 수도 있습니다.

python.exports 확장에는 세 가지 사용자 정의 하위 필드가 있습니다:

• modules: 배포판이 내보내는 모듈
• namespaces: 배포판이 기여하는 네임스페이스 패키지
• exports: 배포판이 내보내는 그 밖의 Python 인터페이스

내보내기 지정자

내보내기 지정자는 완전히 정규화된 이름과, 대괄호로 묶은 선택적 추가 기능(extra) 이름으로 이루어진 문자열입니다. 따라서 내보내기 지정자는 다음 네 가지 형태가 될 수 있습니다:

module
module:name
module[requires_extra]
module:name[requires_extra]

Note

현재 jsonschema 파일은 Python 2의 ASCII 식별자 규칙으로 정규화된 이름을 제한합니다. Python 3의 식별자 규칙이 더 완화되었다는 점을 고려하면 이 부분은 재검토가 필요할 수 있습니다.

하위 필드의 의미는 다음과 같습니다:

• module: 내보내기를 제공하는 모듈
• name: 해당하는 경우, 모듈 안에서 내보내기의 정규화된 이름
• requires_extra: 지정한 추가 기능(extra)에 명시된 추가 의존성을 설치된 환경에서 사용할 수 있을 때에만 내보내기가 올바르게 동작함을 나타냅니다

Note

이것을 하위 필드가 있는 매핑으로 시도해 보았으나, 그렇게 하면 아래 예시들을 읽기 어려워졌습니다. 이 PEP는 주로 도구에서 사용하기 위한 것이지만, 디버깅을 위해 가독성은 여전히 어느 정도 중요하며, 이 형식의 일부가 다른 곳에서도 재사용될 것으로 예상하기 때문이기도 합니다.

모듈

배포판이 임포트할 수 있도록 제공하는 모듈과 패키지의 정규화된 이름 목록입니다.

Note

jsonschema 파일은 현재 Python 2의 ASCII 식별자 규칙으로 정규화된 이름을 제한합니다. Python 3의 식별자 규칙이 더 완화되었으므로 이 제한은 재검토해야 할 수 있습니다.

점을 포함하는 이름의 경우, 마지막 점 앞부분은 설치된 모듈 목록이나 네임스페이스 패키지 목록 중 하나에 반드시(MUST) 나타나야 합니다.

이름 충돌을 피하기 위해, 배포 패키지는 배포 패키지 이름(또는 그 소문자 형태)과 일치하는 단일 최상위 모듈이나 패키지를 제공할 것을 권장합니다(RECOMMENDED). 이렇게 하려면 배포 패키지 이름이 Python 식별자의 요구 사항도 충족해야 하며, 이 요구 사항은 배포 패키지 이름에 대한 요구 사항보다 엄격합니다). 이 관행을 따르면 모듈의 권위 있는 출처를 찾기도 더 쉬워집니다.

색인 서버는 여러 배포 패키지가 같은 모듈을 게시하도록 허용해야 하지만(SHOULD), 잠재적인 충돌을 배포 패키지 작성자에게 알릴 수 있습니다(MAY).

설치 도구는 이전에 설치된 다른 배포 패키지가 이미 제공하는 모듈을 제공하는 배포 패키지를 설치하라는 요청을 받으면 오류를 보고해야 합니다(SHOULD).

적절한 extra가 설치되어 있지 않으면 선언된 일부 모듈을 임포트하려 할 때 예외가 발생할 수 있다는 점에 유의하십시오.

예시:

"modules": ["chair", "chair.cushions", "python_sketches.nobody_expects"]

Note

대신 이것을 내보내기 지정자의 목록으로 만들면, 배포 패키지는 특정 모듈이 올바르게 실행되기 위해 특정 extra가 필요한 경우를 선언할 수 있습니다. 반면에, 그 시점이 엑스트라를 사용하는 대신 별도의 배포를 분리해 내는 것이 가치 있어지기 시작하는 지점이라는 인자도 제기될 수 있습니다.

네임스페이스

배포 패키지가 모듈을 기여하는 네임스페이스 패키지의 정규화된 이름 목록입니다.

Note

jsonschema 파일은 현재 Python 2의 ASCII 식별자 규칙으로 정규화된 이름을 제한합니다. Python 3의 식별자 규칙이 더 완화되었으므로 이 제한은 재검토해야 할 수 있습니다.

Python 3.3(네이티브 네임스페이스 패키지 지원을 제공함) 이전 버전의 Python에서는, 설치 도구가 배포 패키지가 제공하는 파일을 사용하는 대신 네임스페이스를 올바르게 초기화하는 적절한 __init__.py 파일을 생성해야 합니다(SHOULD).

배포 패키지가 이미 설치된 모듈의 이름과 충돌하는 네임스페이스 패키지를 선언하거나 그 반대의 경우, 설치 도구는 경고를 내보내야 하며(SHOULD) 오류를 내보낼 수도 있습니다(MAY).

예시:

"namespaces": ["python_sketches"]

내보내기

exports 필드는 접두사가 붙은 이름을 키로 갖는 매핑입니다. 각 키는 배포 패키지가 게시하는 하나 이상의 내보내기를 포함하는 내보내기 그룹을 식별합니다.

내보내기 그룹 이름은 게시된 내보내기 정보를 어떤 방식으로든 활용할 배포 패키지가 정의합니다. 주요 사용 사례는 플러그인 모델을 지원하는 배포 패키지입니다. 내보내기 그룹을 정의하면 다른 배포 패키지가 자신이 제공하는 플러그인이 무엇인지, 그 플러그인을 어떻게 임포트하고 접근할 수 있는지, 그리고 플러그인이 올바르게 동작하는 데 어떤 추가 의존성이 (있다면) 필요한지를 표시할 수 있습니다.

이름 충돌 가능성을 줄이기 위해, 내보내기 그룹 이름은 해당 내보내기 그룹의 의미를 정의하는 배포 패키지의 모듈 이름에 대응하는 접두사를 사용해야 합니다(SHOULD). 이 관행을 따르면 내보내기 그룹에 대한 권위 있는 문서를 찾기도 더 쉬워집니다.

그러면 각 개별 내보내기 그룹은 비어 있지 않은 임의의 문자열 키를 내보내기 지정자에 대응시키는 매핑이 됩니다. 내보내기 그룹 안에서 내보내기 이름이 갖는 의미는 그 내보내기 그룹을 정의하는 배포 패키지가 결정합니다. 내보내기 이름 형식에 대해 적절한 정의를 만들어 두면, 임포트하는 배포 패키지가 내보내는 모든 모듈을 임포트하지 않고도 어떤 내보내기가 관련 있는지 판단할 수 있습니다.

예시:

"exports": {
  "nose.plugins.0.10": {
    "chairtest": "chair:NosePlugin"
  }
}

python.commands 확장

python.commands 확장은 세 개의 사용자 정의 하위 필드를 포함합니다:

• wrap_console: 설치 프로그램이 생성할 콘솔 래퍼 스크립트
• wrap_gui: 설치 프로그램이 생성할 GUI 래퍼 스크립트
• prebuilt: 배포의 빌드 과정에서 생성되어 설정된 스크립트 디렉터리에 직접 설치되는 스크립트

wrap_console과 wrap_gui는 모두 스크립트 이름을 내보내기 지정자에 대응시키는 매핑입니다. 스크립트 이름은 배포 이름과 동일한 명명 규칙을 따라야 합니다.

래퍼 스크립트의 export 지정자는 (export 지정자에 name 하위 필드가 주어지지 않은 경우) __main__ 하위 모듈이 있는 패키지를 참조하거나, 그렇지 않으면 지정된 모듈 안의 호출 가능 객체를 참조해야 합니다.

설치 도구는 설치 과정의 일부로 적절한 래퍼를 생성해야 합니다.

Note

“적절한 래퍼”가 무엇을 의미하는지에 대해서는 아직 더 자세한 설명이 필요합니다. 당분간은 setuptools와 zc.buildout이 래퍼 스크립트로 생성하는 것을 참고하십시오.

prebuilt는 wheel 파일 안의 또는 설치 후의 scripts 디렉터리를 기준으로 한 상대 스크립트 경로의 목록입니다. 이들은 정보 제공 목적으로만 제공됩니다. 이들의 설치는 배포를 빌드할 때 생성되는 파일에 대한 일반적인 절차를 통해 처리됩니다.

빌드 도구는 이 확장을 설치 프로그램의 처리가 필요한 것으로 표시해야 합니다(SHOULD).

색인 서버는 여러 배포가 동일한 명령을 게시하는 것을 허용해야 하지만(SHOULD), 잠재적인 충돌에 대해 배포 작성자에게 알릴 수 있습니다(MAY).

설치 도구는 이전에 설치된 다른 배포에서도 제공하는 명령을 제공하는 배포를 설치하라는 요청을 받으면 오류를 보고해야 합니다(SHOULD).

예시:

"python.commands": {
  "installer_must_handle": true,
  "wrap_console": [{"chair": "chair:run_cli"}],
  "wrap_gui": [{"chair-gui": "chair:run_gui"}],
  "prebuilt": ["reduniforms"]
}

python.constraints 확장

python.constraints 확장에는 두 개의 사용자 정의 하위 필드가 있습니다:

• environments: 지원되는 설치 환경
• extension_metadata: 설치된 다른 구성 요소가 게시한 확장 메타데이터 필드에서 정확히 일치해야 하는 값

빌드 도구는 이 확장을 설치 프로그램의 처리가 필요한 것으로 표시해야 합니다(SHOULD).

색인 서버는 해당 색인으로는 충족할 수 없는 제약 조건을 가진 배포의 업로드를 허용해야 하지만(SHOULD), 그러한 잠재적인 호환성 문제에 대해 배포 작성자에게 알릴 수 있습니다(MAY).

설치 도구는 배포에 제약 조건이 지정되어 있고 대상 설치 환경이 이를 충족하지 못하면 오류를 보고해야 하며(SHOULD), 최소한 경고는 반드시 출력해야 하고(MUST), 그럼에도 불구하고 사용자가 설치를 강제로 진행하도록 허용할 수 있습니다(MAY).

예시:

"python.constraints": {
  "installer_must_handle": true,
  "environments": ["python_version >= 2.6"],
  "extension_metadata": {
    "fortranlib": {
      "fortranlib.compatibility": {
        "fortran_abi": "openblas-g77"
      }
    }
  }
}

지원되는 환경

environments 하위 필드는 배포가 명시적으로 지원하는 환경을 지정하는 문자열의 목록입니다. 주어진 환경 마커 중 하나 이상과 일치하면 해당 환경은 지원되는 것으로 간주됩니다.

메타데이터에 이 필드가 주어지지 않으면, 배포는 Python이 지원하는 모든 플랫폼을 지원하는 것으로 가정합니다.

개별 항목은 PEP 426에 설명된 환경 마커입니다.

이 필드의 두 가지 주요 용도는 어떤 Python 버전과 어떤 기반 운영 체제가 지원되는지를 선언하는 것입니다.

지원되는 Python 버전을 나타내는 예:

# Supports Python 2.6+
"environments": ["python_version >= '2.6'"]

# Supports Python 2.6+ (for 2.x) or 3.3+ (for 3.x)
"environments": ["python_version >= '3.3'",
                 "'3.0' > python_version >= '2.6'"]

지원되는 운영 체제를 나타내는 예:

# Windows only
"environments": ["sys_platform == 'win32'"]

# Anything except Windows
"environments": ["sys_platform != 'win32'"]

# Linux or BSD only
"environments": ["'linux' in sys_platform",
                 "'bsd' in sys_platform"]

지원되는 Python 버전이 플랫폼에 따라 다른 예:

# The standard library's os module has long supported atomic renaming
# on POSIX systems, but only gained atomic renaming on Windows in Python
# 3.3. A distribution that needs atomic renaming support for reliable
# operation might declare the following supported environments.
"environment": ["python_version >= '2.6' and sys_platform != 'win32'",
                "python_version >= '3.3' and sys_platform == 'win32'"]

확장 메타데이터 제약 조건

extension_metadata 하위 필드는 배포 이름을 확장 메타데이터 조각에 대응시키는 매핑입니다. 각 조각은 대상 설치 환경에 있는 해당 배포의 메타데이터와 정확히 일치해야 합니다.

각 하위 매핑은 다시 메타데이터 확장 이름을 일부 필드의 정확한 기대값에 대응시키는 매핑으로 구성됩니다.

예를 들어 fortranlib이라는 배포는 빌드 방식에 따라 서로 다른 FORTRAN ABI를 게시할 수 있습니다. 따라서 같은 런타임 환경에 설치되는 관련 프로젝트는 모두 이와 일치하는 빌드 옵션을 사용해야 합니다. 이 문제는 기반 배포가 사용자 정의 확장을 게시하도록 하여 처리할 수 있습니다. 이 확장은 바이너리 확장을 만들 때 사용한 빌드 옵션을 나타냅니다.:

"extensions": {
  "fortranlib.compatibility": {
    "fortran_abi": "openblas-g77"
  }
}

그러면 기반 배포와 호환되어야 하는 바이너리 확장을 포함한 다른 배포는 자신의 메타데이터에 적절한 제약 조건을 정의합니다.:

"python.constraints": {
  "installer_must_handle": true,
  "extension_metadata": {
    "fortranlib": {
      "fortranlib.compatibility": {
        "fortran_abi": "openblas-g77"
      }
    }
  }
}

이 제약 조건은 다음을 지정합니다:

• fortranlib가 설치되어 있어야 합니다(설치 프로그램이 이를 충족하도록 보장하기 위해 일반 의존성으로도 표현해야 합니다)
• 설치된 fortranlib 버전은 게시된 메타데이터에 사용자 정의 fortranlib.compatibility 확장을 포함해야 합니다.
• 해당 확장의 fortan_abi 하위 필드 값은 정확히 openblas-g77이어야 합니다.

이 조건들(배포가 설치되어 있고, 지정된 확장이 메타데이터에 포함되어 있으며, 지정된 하위 필드가 지정된 값과 정확히 같음)이 모두 충족되면 제약 조건이 만족된 것으로 간주합니다.

Note

여기서 주로 의도한 사용 사례는 추가적인 ABI 호환성 요구 사항이 있는 C 확장이 그 요구 사항을 선언하도록 하는 것입니다. 이 선언은 어떤 설치 도구든 세부 사항을 이해하지 않고도 강제할 수 있는 방식이어야 합니다. 특히 NumPy 기반 과학 라이브러리 상당수는 일관된 FORTRAN 라이브러리 조합으로 빌드해야 하므로 “fortranlib” 예제를 들었습니다.

패턴 매칭이나 불리언 논리를 지원하지 않는 이유도 여기에 있습니다. 이 확장은 “단순한” 버전조차 비교적 복잡하며, 현재로서는 지금보다 더 복잡하게 만들 만한 설득력 있는 근거가 없습니다.

Copyright

This document has been placed in the public domain.