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

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 확장
  • 라이선스
  • 키워드
  • 분류자
  • 문서 이름
• 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는 파이썬 메타데이터에 대한 몇 가지 표준 확장을 설명합니다.

모든 메타데이터 확장과 마찬가지로 각 표준 확장 형식은 독립적으로 버전이 지정됩니다. 형식 중 하나라도 변경하려면 이 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: 추가 메타데이터 파일의 이름

이 모든 필드는 선택 사항입니다. 자동화 도구는 배포에서 이러한 필드를 제공하지 않더라도 올바르게 작동해야 하며, 이러한 필드 중 하나에 의존하는 작업이 요청될 때 정상적으로 실패해야 합니다.

라이선스

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

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

이 필드에는 512자 미만이 포함되어야 하며 2048자 미만이어야 합니다.

이 필드에는 줄 바꿈이 포함되어서는 안 됩니다.

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

예:

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

키워드

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

예:

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

분류자

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

예:

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

문서 이름

배포판의 dist-info 메타데이터 디렉터리에 포함되는 지원 문서의 파일 이름입니다.

다음 지원 문서의 이름을 지정할 수 있습니다.

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

지원 문서는 dist-info 디렉터리에 직접 포함되어야 합니다. 디렉터리 구분자는 문서 이름에 사용할 수 없습니다.

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

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

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

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

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

자동화 도구는 서비스의 무결성을 보호하는 데 필요한 경우를 제외하고, 지원 문서 콘텐츠의 최대 길이에 관해 어떠한 가정도 해서는 안 됩니다.

예제:

"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: 배포 패키지의 생성에 관여한 그 밖의 개인 또는 조직

연락처 및 기여자 메타데이터는 선택 사항입니다. 자동화 도구는 배포 패키지가 해당 정보를 제공하지 않더라도 올바르게 작동해야 하며, 이러한 필드 중 하나에 의존하는 작업이 요청된 경우에도 정상적으로 실패해야 합니다.

연락처

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

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

예제:

"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을 자유롭게 선택할 수 있지만, 아래 예시의 레이블을 사용하여 홈페이지, 소스 제어, 이슈 추적기 및 문서 링크를 제공하는 것이 권장됩니다.

자동화된 도구는 URL 레이블을 대소문자를 구분하지 않는 것으로 처리해야 하지만, 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 메타데이터는 수정된 버전을 다운스트림에서 재배포하는 주체를 가리킵니다.

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

체인에 여러 재배포자가 있는 경우 각 재배포자는 자신의 특정 메타데이터로 이 확장을 덮어쓰기만 합니다.

python.exports 확장

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

python.exports 확장에는 세 개의 사용자 정의 하위 필드가 포함됩니다.

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

내보내기 지정자

내보내기 지정자는 완전히 수식된 이름과 대괄호로 묶인 선택적 추가 이름으로 구성된 문자열입니다. 이에 따라 내보내기 지정자는 다음 네 가지 형식 중 하나가 될 수 있습니다.:

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의 더 완화된 식별자 규칙을 고려하면 이 부분은 재검토해야 할 수 있습니다.

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

이름 충돌을 방지하기 위해 배포 패키지는 배포 패키지 이름과 일치하는 단일 최상위 모듈 또는 패키지(또는 소문자로 변환한 이름)를 제공하는 것이 권장됩니다. 이를 위해서는 배포 패키지 이름도 Python 식별자의 요구 사항을 충족해야 하며, 이러한 요구 사항은 배포 이름에 적용되는 요구 사항보다 더 엄격합니다). 또한 이 관행을 따르면 모듈에 대한 신뢰할 수 있는 출처를 더 쉽게 찾을 수 있습니다.

패키지 색인 서버는 여러 배포 패키지가 동일한 모듈을 게시하도록 허용하는 것이 권장되지만, 잠재적인 충돌을 배포 패키지 작성자에게 알릴 수 있습니다.

설치 도구는 다른 배포 패키지가 이미 제공하고 있으며 이전에 설치된 배포 패키지가 제공하는 모듈을 제공하는 배포 패키지를 설치하라는 요청을 받으면 오류를 보고하는 것이 권장됩니다.

선언된 일부 모듈을 가져오려고 할 때 적절한 추가 기능이 설치되어 있지 않으면 예외가 발생할 수 있음에 유의하십시오.

예제:

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

Note

이를 내보내기 지정자 목록으로 대신 만들면 배포 패키지가 특정 모듈을 올바르게 실행하려면 특정 추가 기능이 필요한 경우를 선언할 수 있습니다. 반면, 추가 기능을 사용하는 대신 별도의 배포 패키지로 분리하는 것이 유용해지기 시작하는 지점이 바로 그때라는 주장도 있습니다.

네임스페이스

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

Note

jsonschema 파일은 현재 Python 2 ASCII 식별자 규칙을 사용하여 정규화된 이름을 제한합니다. Python 3의 더 완화된 식별자 규칙을 고려하면 이 부분은 재검토해야 할 수 있습니다.

네이티브 네임스페이스 패키지 지원을 제공하는 Python 3.3 이전 버전에서는 설치 도구가 배포 패키지가 제공하는 파일을 사용하는 대신 네임스페이스를 올바르게 초기화할 수 있도록 적절한 __init__.py 파일을 생성하는 것이 권장됩니다.

배포 패키지가 이미 설치된 모듈의 이름과 충돌하는 네임스페이스 패키지를 선언하거나 그 반대의 경우, 설치 도구는 경고를 출력하는 것이 권장되며 오류를 출력할 수도 있습니다.

예제:

"namespaces": ["python_sketches"]

내보내기

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

내보내기 그룹 이름은 배포 패키지가 정의하며, 배포 패키지는 이후 게시된 내보내기 정보를 어떤 방식으로든 활용합니다. 주요 사용 사례는 플러그인 모델을 지원하는 배포 패키지입니다. 내보내기 그룹을 정의하면 다른 배포 패키지가 어떤 플러그인을 제공하는지, 해당 플러그인을 어떻게 가져오고 액세스할 수 있는지, 플러그인이 올바르게 작동하는 데 필요한 추가 종속성이 있는지를 나타낼 수 있습니다.

이름 충돌 가능성을 줄이기 위해 내보내기 그룹 이름은 내보내기 그룹의 의미를 정의하는 배포 패키지의 모듈 이름에 해당하는 접두사를 사용하는 것이 권장됩니다. 또한 이 관행을 따르면 내보내기 그룹에 대한 신뢰할 수 있는 문서를 더 쉽게 찾을 수 있습니다.

그런 다음 각 개별 내보내기 그룹은 임의의 비어 있지 않은 문자열 키를 내보내기 지정자에 매핑하는 매핑이 됩니다. 내보내기 그룹 내 내보내기 이름의 의미는 해당 내보내기 그룹을 정의하는 배포 패키지에 달려 있습니다. 내보내기 이름 형식에 대한 적절한 정의를 만들면 가져오는 배포 패키지가 모든 내보내기 모듈을 가져오지 않고도 특정 내보내기가 관련 있는지 여부를 판단할 수 있습니다.

예제:

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

python.commands 확장

python.commands 확장에는 세 개의 사용자 지정 하위 필드가 포함됩니다.

• wrap_console: 설치 관리자가 생성할 콘솔 래퍼 스크립트
• wrap_gui: 설치 관리자가 생성할 GUI 래퍼 스크립트
• prebuilt: 배포판의 빌드 프로세스에서 생성되어 구성된 스크립트 디렉터리에 직접 설치되는 스크립트

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

래퍼 스크립트의 내보내기 지정자는 __main__ 서브모듈이 있는 패키지(내보내기 지정자에 name 하위 필드가 지정되지 않은 경우) 또는 지정된 모듈 내부의 호출 가능 객체를 가리켜야 합니다.

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

Note

“적절한 래퍼”가 무엇을 의미하는지에 대해서는 여전히 더 자세한 설명이 필요합니다. 현재로서는 setuptools와 zc.buildout이 래퍼 스크립트로 생성하는 것을 참조하십시오.

prebuilt는 휠 파일의 스크립트 디렉터리 또는 설치 후의 스크립트 디렉터리를 기준으로 하는 스크립트 경로 목록입니다. 이는 정보 제공 목적으로만 제공되며 - 설치는 배포판을 빌드할 때 생성되는 파일에 대한 일반적인 프로세스를 통해 처리됩니다.

빌드 도구는 이 확장을 설치 관리자가 처리해야 하는 것으로 표시해야 합니다.

패키지 색인 서버는 여러 배포판이 동일한 명령을 게시하도록 허용해야 하지만, 잠재적인 충돌을 배포판 작성자에게 알릴 수 있습니다.

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

예시입니다.:

"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: 설치된 다른 구성 요소가 게시한 확장 메타데이터 필드에서 요구되는 정확한 일치 항목

빌드 도구는 이 확장을 설치 관리자가 처리해야 하는 것으로 표시해야 합니다.

패키지 색인 서버는 해당 색인을 사용하여 충족할 수 없는 제약 조건이 포함된 배포판의 업로드를 허용해야 하지만, 그러한 잠재적인 호환성 문제를 배포판 작성자에게 알릴 수 있습니다.

설치 도구는 배포판에 제약 조건이 지정되어 있고 대상 설치 환경이 이를 충족하지 못하면 오류를 보고해야 하며, 최소한 경고를 내보내야 하고, 사용자가 그와 관계없이 설치를 진행하도록 강제할 수 있게 허용할 수 있습니다.

예시입니다.:

"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.