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

Python 개선 제안 한국어 번역

PEP 423 – 패키징과 관련된 명명 규칙 및 레시피

Author:
Benoit Bryon <benoit at marmelune.net>
Discussions-To:
Distutils-SIG list
Status:
Deferred
Type:
Informational
Topic:
Packaging
Created:
24-May-2012
Post-History:

Table of Contents

번역·라이선스 안내

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

초록

이 문서는 다음을 다룹니다.

  • Python 프로젝트의 이름,
  • 배포되는 Python 패키지 또는 모듈의 이름,
  • 네임스페이스 패키지입니다.

배포 작성자를 위한 지침과 레시피를 제공합니다.

PEP 유보

이 PEP에 대한 추가 검토는 PEP 426(패키지 메타데이터 2.0) 및 관련 업데이트가 해결된 이후까지 최소한 연기되었습니다.

용어

packaging terminology in Python documentation을 참조하십시오.

다른 PEP와의 관계

  • PEP 8은 Python 패키지와 모듈의 이름을 포함한 코드 스타일 가이드를 다룹니다. 패키지 및 모듈 이름의 구문을 다룹니다.
  • PEP 345은 패키징 메타데이터를 다루며, packaging.core.setup() 함수의 name 인자를 정의합니다.
  • PEP 420은 네임스페이스 패키지를 다룹니다. Python 코어에서 네임스페이스 패키지를 지원하도록 합니다. 이전에는 네임스페이스 패키지가 외부 라이브러리로 구현되었습니다.
  • PEP 3108은 표준 라이브러리에 적용되는 Python 2.x와 Python 3.x 간의 전환을 다룹니다. 일부 모듈은 삭제되고 일부 모듈은 이름이 변경됩니다. 명명 규칙이 중요하다는 점을 지적하며 전환 계획의 한 예입니다.

개요

이름을 선택할 때 따라야 할 지침을 요약하면 다음과 같습니다.

확신이 서지 않는다면 질문하십시오.

이 문서를 읽은 후에도 확신이 서지 않으면 IRC나 메일링 리스트에서 Python community에 문의하십시오.

최상위 네임스페이스는 코드 소유권과 관련됩니다.

이는 프로젝트 이름 간의 충돌을 피하는 데 도움이 됩니다.

소유자는 다음과 같을 수 있습니다:

  • 개인입니다. 예: gp.fileupload은 Gael Pasgrimaud가 소유하고 유지 관리합니다.
  • 조직입니다. 예시는 다음과 같습니다:
    • zest.releaser는 Zest Software가 소유하고 유지 관리합니다.
    • Django는 Django Software Foundation이 소유하고 유지 관리합니다.
  • 그룹 또는 커뮤니티입니다. 예: sphinx는 저자인 Georg Brandl뿐만 아니라 Sphinx 프로젝트의 개발자들이 유지 관리합니다.
  • 다른 패키지와 관련된 그룹 또는 커뮤니티입니다. 예: collective.recaptcha는 작성자인 Groundwire의 David Glick이 소유합니다. 그러나 “collective” 네임스페이스는 Plone 커뮤니티가 소유합니다.

소유권을 존중하십시오

네임스페이스를 사용하기 전에 그 목적을 이해하십시오.

명시적으로 승인받지 않았다면 자신이 소유하지 않은 네임스페이스에 연결하지 마십시오.

확실하지 않으면 If in doubt, ask.

예를 들어, “django.contrib” 네임스페이스는 Django의 핵심 기여자들이 관리하므로 여기에 연결하지 마십시오.

예외는 프로젝트 작성자가 정의할 수 있습니다. 아래의 Organize community contributions을 참조하십시오.

또한 이 규칙은 Python이 아닌 프로젝트에도 적용됩니다.

예를 들어, “apache”를 최상위 네임스페이스로 사용하지 마십시오. “Apache”는 기존 프로젝트의 이름이며(“Apache”의 경우 상표이기도 합니다).

비공개(비공개 소스 포함) 프로젝트는 네임스페이스를 사용합니다.

… 비공개 프로젝트는 누군가가 소유하기 때문입니다. 따라서 소유권 규칙을 적용하십시오.

내부용 또는 고객용 프로젝트에는 회사 이름을 네임스페이스로 사용하십시오.

이 규칙은 비공개 소스 프로젝트에 적용됩니다.

예를 들어, “Python Sport” 회사를 위한 “climbing” 프로젝트를 만든다면 비공개 소스이더라도 “pythonsport.climbing”이라는 이름을 사용하십시오.

개인 프로젝트는 네임스페이스를 사용합니다.

… 개인이 소유하기 때문입니다. 따라서 소유권 규칙을 적용하십시오.

프로젝트 이름이 “내부용” 또는 “개인용”이더라도 오픈 소스로 공개하는 것은 부끄러운 일이 아닙니다.

프로젝트가 개인의 소유가 아니게 되어 작성자가 소유권을 변경하려는 시점에 이르면, 프로젝트 이름을 쉽게 변경할 수 있습니다라는 점을 기억하십시오.

커뮤니티 소유 프로젝트는 네임스페이스 패키지를 사용하지 않아도 됩니다.

프로젝트가 충분히 일반적이라면(즉, 다른 제품이나 프레임워크에 기여하는 것이 아니라면) 네임스페이스 패키지를 사용하지 않아도 됩니다. 일반적으로 기본 조건은 프로젝트에 전념하는 그룹(즉, 개발 팀)이 프로젝트를 소유하는 것입니다.

코드가 실제로 커뮤니티 소유가 되도록 의도하는 경우에만 “shared” 네임스페이스를 사용하십시오.

예를 들어, sphinx 프로젝트는 Sphinx 개발 팀에 속합니다. 내부에 “sphinx.sphinx” 프로젝트 하나만 있는 “sphinx” 네임스페이스 패키지를 만들 필요는 없습니다.

확신이 서지 않으면 개인 또는 조직 네임스페이스를 사용하십시오.

프로젝트가 정말 실험적이라면 개인 또는 조직 네임스페이스를 사용하는 것이 가장 좋습니다.

  • 이를 통해 프로젝트를 일찍 공개할 수 있습니다.
  • 프로젝트가 중단되더라도 이름을 선점하지 않습니다.
  • 향후 변경을 막지도 않습니다. 프로젝트가 성숙해져 개인 소유를 유지할 이유가 없어지더라도 프로젝트 이름을 변경할 수 있습니다.

단일 이름 사용

프로젝트마다 패키지 하나(또는 모듈 하나)만 배포하고, 패키지(또는 모듈) 이름을 프로젝트 이름으로 사용하십시오.

  • 프로젝트 이름과 배포된 패키지 또는 모듈 이름 사이에서 발생할 수 있는 혼동을 방지합니다.
  • 이름의 일관성을 유지합니다.
  • 명확합니다. 프로젝트 이름을 보면 패키지/모듈 이름을 추측할 수 있고, 그 반대도 마찬가지입니다.
  • 패키지/모듈 이름 사이의 암묵적인 충돌도 제한합니다. 단일 이름을 사용하면 PyPI에 프로젝트 이름을 등록할 때 기본적인 패키지/모듈 이름 사용 가능 여부 확인도 수행합니다.

    예를 들어 pipeline, python-pipeline 및 django-pipeline은 모두 “pipeline”이라는 패키지 또는 모듈을 배포합니다. 따라서 이 중 두 개를 설치하면 오류가 발생합니다. 이러한 배포판이 단일 이름을 사용했다면 이 문제는 발생하지 않았을 것입니다.

예:

  • 패키지 이름: “kheops.pyramid”, 즉 import kheops.pyramid
  • 프로젝트 이름: “kheops.pyramid”, 즉 pip install kheops.pyramid

아니오:

  • 패키지 이름: “kheops”
  • 프로젝트 이름: “KheopsPyramid”

Note

역사적인 이유로 PyPI에는 프로젝트 이름과 배포된 패키지/모듈 이름이 서로 다른 배포판이 많이 포함되어 있습니다.

여러 패키지/모듈은 드물어야 합니다.

기술적으로 Python 배포판은 여러 패키지 및/또는 모듈을 제공할 수 있습니다. 자세한 내용은 setup script reference을 참조하십시오.

실제로 그렇게 하는 배포판도 일부 있습니다. 예를 들어 setuptools와 distribute는 각각의 “setuptools” 및 “distribute” 패키지와 더불어 “pkg_resources”, “easy_install” 및 “site” 모듈을 선언합니다.

이 사용 사례는 예외적인 경우로 간주하십시오. 대부분의 경우 이 기능은 필요하지 않습니다. 따라서 배포판은 한 번에 패키지 또는 모듈 하나만 제공해야 합니다.

서로 다른 이름은 드물어야 합니다.

Use a single name 규칙의 주목할 만한 예외는 서로 다른 이름이 명시적으로 필요한 경우입니다.

예를 들어 Pillow 프로젝트는 기존 PIL 배포판의 대안을 제공합니다. 두 프로젝트 모두 “PIL” 패키지를 배포합니다.

이 사용 사례는 예외적인 경우로 간주하십시오. 대부분의 경우 이 기능은 필요하지 않습니다. 따라서 배포된 패키지 이름은 프로젝트 이름과 같아야 합니다.

패키지 및 모듈 이름의 구문에는 PEP 8을 따르십시오.

PEP 8은 Python 패키지 및 모듈의 이름에 적용됩니다.

Use a single name을 사용하는 경우, PEP 8은 프로젝트 이름에도 적용됩니다. 예외는 프로젝트 이름에 점이 필수인 네임스페이스 패키지입니다.

기억하기 쉬운 이름을 선택하십시오.

프로젝트 이름에서 중요한 점 중 하나는 기억하기 쉬워야 한다는 것입니다.

예를 들어, celery는 의미 있는 이름이 아닙니다. 처음에는 메시지 큐잉을 처리한다는 점이 분명하지 않습니다. 그러나 RabbitMQ 서버에 데이터를 공급하는 데 사용할 수 있기 때문에 어느 정도 기억하기 쉽습니다.

의미 있는 이름을 선택하십시오.

스스로 “이 이름이 무엇을 위한 것인지 한 문장으로 어떻게 설명할 수 있을까?”라고 물은 다음, “이름을 보고 누구라도 추측할 수 있었을까?”라고 물어보십시오.

예를 들어, DateUtils는 의미 있는 이름입니다. 날짜를 위한 유틸리티를 처리한다는 점이 분명합니다.

네임스페이스를 사용할 때는 각 부분을 의미 있게 만들도록 하십시오.

패키징 메타데이터를 사용하십시오.

프로젝트 이름을 PyPI의 고유 식별자로 간주하십시오.

  • 이러한 식별자는 사람이 읽을 수 있는 상태로 유지하는 것이 중요합니다.
  • 이러한 식별자가 의미를 가지면 더 좋습니다.
  • 그러나 식별자의 주된 목적은 프로젝트를 분류하거나 설명하는 것이 아닙니다.

분류자 및 키워드 메타데이터는 배포 패키지를 분류하기 위한 것입니다. 요약 및 설명 메타데이터는 프로젝트를 설명하기 위한 것입니다.

예를 들어 “Framework :: Twisted” 분류자가 있습니다. 이름이 상당히 이질적이더라도(특정 패턴을 따르지 않더라도) 목록을 얻을 수 있습니다.

Organize community contributions을 위해서는 이름과 네임스페이스에 관한 규칙이 중요하지만, 메타데이터에 관한 규칙은 훨씬 더 중요해야 합니다.

예를 들어 여러 곳에서 Plone 포틀릿을 찾을 수 있습니다.

  • plone.portlet.*
  • collective.portlet.*
  • collective.portlets.*
  • collective.*.portlets
  • “quintagroup.portlet.cumulus”와 같은 일부 공급업체 관련 프로젝트
  • 그리고 이름에 “portlet” 패턴이 나타나지 않는 프로젝트도 있습니다.

Plone 커뮤니티에 관례가 있더라도, 이름을 사용하여 배포 패키지를 분류하는 것은 적절하지 않습니다. 이름으로 필터링하여 Plone용 포틀릿을 제공하는 배포 패키지의 전체 목록을 얻는 것은 불가능합니다. 그러나 이러한 배포 패키지가 모두 “Framework :: Plone” 분류자와 “portlet” 키워드를 사용한다면 가능할 것입니다.

깊은 중첩을 피하십시오.

The Zen of Python은 “중첩된 것보다 평평한 것이 낫습니다”라고 말합니다.

거의 항상 두 수준이면 충분합니다.

모든 것을 깊게 중첩된 계층 구조로 정의하지 마십시오. 그러면 “pythonsport.common.maps.forest”와 같은 프로젝트와 패키지를 만들게 됩니다. 이러한 유형의 이름은 장황하고 번거롭기도 합니다(예를 들어 패키지에서 많은 항목을 임포트하는 경우).

또한 서로 다른 패키지 사이의 경계가 모호해지면서 큰 계층 구조는 시간이 지남에 따라 붕괴하는 경향이 있습니다.

일반적인 합의는 두 수준의 중첩을 선호하는 것입니다.

예를 들어 plone.source.principal 또는 이와 비슷한 이름 대신 plone.principalsource를 사용합니다. 이름이 더 짧고 패키지 구조가 더 단순하며, 여기에서 세 수준의 중첩을 사용해도 얻을 수 있는 이점은 거의 없습니다. 모든 “core Plone” 소스(소스는 일종의 보캐뷸러리입니다)를 plone.source.* 네임스페이스에 넣으려는 것은 실용적이지 않습니다. 일부 소스는 다른 패키지에 속하고, 소스가 이미 다른 곳에도 존재하기 때문입니다. 새 네임스페이스를 만들었다면 처음부터 일관성 없이 사용되었을 것입니다.

예: “pyranha”

예: “pythonsport.climbing”

예: “pythonsport.forestmap”

아니요: “pythonsport.maps.forest”

소유권에는 한 수준만 사용하십시오.

커뮤니티 네임스페이스에서 개인 또는 조직의 소유권을 설정하기 위해 3개 수준을 사용하지 마십시오.

다음 예를 살펴보겠습니다:

  • “collective”와 같은 커뮤니티 네임스페이스에 연결한다고 가정하십시오.
  • 그리고 커뮤니티 내부의 충돌을 피하기 위해 더 제한적인 “소유권” 수준을 추가하려고 한다고 가정하십시오.

이러한 경우 가장 제한적인 소유권 수준을 첫 번째 수준으로 사용하는 것이 좋습니다.

“collective”가 “gergovie”가 속한 주요 커뮤니티 네임스페이스이고, “vercingetorix”가 “gergovie” 작성자의 이름인 경우를 예로 들어 보겠습니다.

아니요: “collective.vercingetorix.gergovie”

예: “vercingetorix.gergovie”

분류를 위해 네임스페이스 수준을 사용하지 마십시오.

Use packaging metadata대신 사용하십시오.

3개 수준을 초과하여 사용하지 마십시오.

기술적으로는 깊게 중첩된 계층 구조를 만들 수 있습니다. 그러나 대부분의 경우 그렇게 할 필요는 없습니다.

Note

네임스페이스가 표준인 커뮤니티에서도 3개 수준을 초과하여 사용하지 않습니다.

커뮤니티 또는 관련 프로젝트의 규칙

해당하는 경우 커뮤니티 또는 관련 프로젝트의 규칙을 따르십시오.

프로젝트 또는 관련 커뮤니티에는 이 문서에서 설명하는 규칙과 다를 수 있는 특정 규칙이 있을 수 있습니다.

이러한 경우 문서에 구체적인 규칙을 선언해야 합니다.

따라서 프로젝트가 다른 프로젝트나 커뮤니티에 속한다면, 먼저 주 프로젝트의 문서에서 구체적인 규칙을 찾아보십시오.

구체적인 규칙이 없다면 이 문서에 선언된 규칙을 따르십시오.

예를 들어, Plone community는 “collective” 네임스페이스 패키지로 커뮤니티 기여를 배포합니다. 이는 여기에서 제안하는 기여를 위한 표준 네임스페이스와 다릅니다. 그러나 문서화되어 있으므로 모호함이 없으며, 이 구체적인 규칙을 따라야 합니다.

커뮤니티 기여에 표준 패턴 사용

구체적인 규칙이 정의되어 있지 않은 경우, 다음과 같은 제품 또는 프레임워크의 커뮤니티 기여를 저장할 때 ${MAINPROJECT}contrib.${PROJECT} 패턴을 사용하십시오:

  • ${MAINPROJECT}는 관련 프로젝트의 이름입니다. 아래 예에서는 “pyranha”입니다.
  • ${PROJECT}는 프로젝트의 이름입니다. 아래 예에서는 “giantteeth”입니다.

예:

  • “pyranha” 프로젝트의 작성자라고 가정하십시오. “pyranha” 네임스페이스를 소유합니다.
  • 커뮤니티 기여에 대한 구체적인 명명 규칙을 정의하지 않았습니다.
  • 서드파티 개발자가 커뮤니티 네임스페이스에서 사용자의 “pyranha” 프로젝트와 관련된 “giantteeth” 프로젝트를 게시하려고 합니다. 따라서 이를 “pyranhacontrib.giantteeth”로 게시해야 합니다.

이는 Organize community contributions을 수행하는 가장 간단한 방법입니다.

Note

왜 ${MAINPROJECT}contrib.* 패턴인가?

  • ${MAINPROJECT}c.*는 충분히 명시적이지 않습니다. 예를 들어 “zc”는 “Zope Corporation”에 속하는 반면, “z3c”는 “Zope 3 community”에 속합니다.
  • ${MAINPROJECT}community는 너무 깁니다.
  • ${MAINPROJECT}community는 “iccommunity” 또는 “PyCommunity”와 같은 기존 네임스페이스와 충돌합니다.
  • ${MAINPROJECT}.contrib.*는 ${MAINPROJECT} 네임스페이스 내부에 있으므로 ${MAINPROJECT} 작성자가 소유합니다. 이는 Top-level namespace relates to code ownership 규칙을 위반합니다.
  • ${MAINPROJECT}.contrib.*은 Avoid deep nesting 규칙을 위반합니다.
  • ${MAINPROJECT}가 나타나지 않는 이름은 충분히 명시적이지 않으므로, 누구도 해당 이름이 ${MAINPROJECT}와 관련되어 있다고 추측할 수 없습니다. 예를 들어 “collective.*”가 Plone 커뮤니티에 속한다는 것은 분명하지 않습니다.
  • {$DIST}contrib.*은 기존 sphinxcontrib-* 패키지처럼 보입니다. 그러나 sphinxcontrib-*은 실제로 Sphinx contrib에 관한 것이므로, 이는 실제 충돌이 아닙니다… 사실 “contrib” 접미사는 “sphinxcontrib”에서 영감을 받았습니다.

커뮤니티 기여를 구성하십시오

이는 커뮤니티 관례 따르기 및 기여를 위한 표준 패턴 규칙에 대응하는 규칙입니다.

작업:

  • 커뮤니티 기여를 위한 명명 관례를 선택하십시오.
  • 그것이 기본값이 아니라면 문서화하십시오.
    • 기본 관례을 사용한다면 이 문서로 충분합니다. 반복해서 작성하지 마십시오. 이를 참조할 수 있습니다.
    • 그렇지 않다면 프로젝트의 “contribute” 또는 “create modules” 문서에서 사용자에게 사용자 지정 관례를 알려 주십시오.
  • 또한 분류자 및 키워드와 같은 추가 메타데이터의 사용을 권장하십시오.

관례 선택에 관하여:

  • 새 프로젝트는 기본 contrib 패턴을 선택해야 합니다.
  • 커뮤니티 기여가 있는 기존 프로젝트는 사용자 지정 관례로 시작해야 합니다. 그러면 Promote migrations할 수 있습니다.

    이는 기존 커뮤니티 관례를 변경할 필요가 없다는 의미입니다. 그러나 최소한 이를 명시적으로 문서화해야 합니다.

예: “pyranha”가 프로젝트 이름이자 패키지 이름이라고 하겠습니다. 기여자에게 다음과 같이 알려 주십시오.

  • pyranha 관련 배포판은 “pyranha” 키워드를 사용해야 합니다.
  • 템플릿을 제공하는 pyranha 관련 배포판은 “templates” 키워드도 사용해야 합니다.
  • 커뮤니티 기여는 “pyranhacontrib” 네임스페이스로 릴리스해야 합니다(즉, “pyranhacontrib.*” 패턴을 사용해야 합니다).

PyPI에 이름을 등록하십시오

PyPI는 Python 커뮤니티에서 배포판을 위한 중앙 장소입니다. 따라서 프로젝트 및 패키지 이름을 등록하는 장소이기도 합니다.

자세한 내용은 Registering with the Package Index를 참조하십시오.

레시피

다음 레시피를 따르면 위의 지침과 관례를 준수하는 데 도움이 됩니다.

이름 사용 가능 여부를 확인하는 방법은 무엇입니까?

프로젝트 이름을 선택하기 전에 다음 위치에 이미 등록되어 있지 않은지 확인하십시오:

  • PyPI
  • 그게 전부입니다. PyPI가 유일한 공식 장소입니다.

예를 들어 인기 있는 코드 호스팅 서비스 등 여러 장소도 확인할 수 있지만, Python 커뮤니티에서 이름을 등록할 수 있는 유일한 장소는 PyPI라는 점을 명심하십시오.

그렇기 때문에 Register names with PyPI이 중요합니다.

또한 배포 패키지나 모듈의 이름이 이미 등록되지 않았는지 확인하십시오.

  • Python Standard Library에서 확인하십시오.
  • PyPI의 프로젝트 내부에서도 확인하십시오. 현재 이를 위한 도우미는 없습니다. 더 많은 프로젝트가 Use a single name 규칙을 따를수록 확인이 더 쉬워진다는 점에 유의하십시오.
  • ask the community할 수도 있습니다.

Use a single name 규칙은 패키지 이름과의 충돌도 피하는 데 도움이 됩니다. 프로젝트 이름을 사용할 수 있다면 패키지 이름도 사용할 수 있을 가능성이 높습니다.

프로젝트 이름을 변경하려면 어떻게 해야 합니까?

프로젝트 이름을 변경할 수 있지만, 혼란이 발생할 수 있다는 점을 명심하십시오. 따라서 사용자가 무슨 일이 있었는지 이해할 수 있도록 README와 문서에 특히 주의를 기울이십시오.

  1. 무엇보다도 PyPI에서 레거시 배포 패키지를 삭제하지 마십시오. 일부 사용자가 이를 사용하고 있을 수 있기 때문입니다.
  2. 레거시 프로젝트를 복사한 다음 이름을 변경하십시오(프로젝트 및 패키지/모듈). 최소한 다음 항목에 주의를 기울이십시오.
    • 패키징 파일
    • 소스 파일이 들어 있는 폴더 이름
    • README를 포함한 문서
    • 코드의 import 문
  3. setup.cfg 파일에서 새 배포 패키지에 Obsoletes-Dist 메타데이터를 지정하십시오. 자세한 내용은 PEP 345 about Obsolete-Dist 및 setup.cfg specification을 참조하십시오.
  4. 이름을 변경한 프로젝트의 새 버전을 릴리스한 다음 게시하십시오.
  5. 레거시 프로젝트를 편집하십시오.
    • 새 프로젝트에 대한 의존성을 추가하십시오.
    • 패키징 관련 항목을 제외한 모든 것을 제거하십시오.
    • setup 스크립트에 Development Status :: 7 - Inactive 분류자를 추가하십시오.
    • 새 릴리스를 게시하십시오.

그러면 레거시 패키지의 사용자는 다음과 같습니다.

  • 폐기된 버전의 레거시 배포판을 계속 사용할 수 있습니다.
  • 내용이 비어 있는 레거시 배포판의 최신 버전으로 업그레이드할 수 있습니다…
  • … 그리고 레거시 배포판의 종속 항목으로 새 배포판을 자동으로 다운로드합니다.

레거시 프로젝트를 발견한 사용자는 해당 프로젝트가 비활성 상태임을 알게 됩니다.

PyPI에서 이름이 변경된 프로젝트의 처리 개선

많은 프로젝트가 Renaming howto 레시피를 따르면 많은 레거시 배포판이 다음과 같은 특징을 갖게 됩니다.

  • Development Status :: 7 - Inactive 분류자입니다.
  • 최신 버전은 패키징 관련 내용을 제외하면 비어 있습니다.
  • 최신 버전이 다른 배포판으로 “리디렉션됩니다”. 예를 들어, 이름이 변경된 프로젝트에 대한 단일 종속 항목만 포함합니다.
  • 새 배포판에서 Obsoletes-Dist로 참조됩니다.

따라서 이름이 변경된 프로젝트를 감지하고 PyPI에서 가독성을 향상할 수 있습니다. 이를 통해 사용자는 활성 상태인 배포판에 집중할 수 있습니다. 그러나 지금 이 기능은 필요하지 않습니다. 서두를 필요가 없습니다. 이 문서에서는 다루지 않습니다.

기존 프로젝트에 명명 지침을 적용하려면 어떻게 해야 합니까?

기존 프로젝트의 이름을 변경할 의무는 없습니다. 명백한 이유로 선택은 프로젝트 작성자와 유지 관리자에게 맡겨집니다.

그러나 프로젝트 작성자에게 다음을 권장합니다.

현재 명명에 관해 밝히기

우선 중요한 것은 현재의 선택 사항을 밝히는 것입니다.

  • 스스로에게 “왜 현재 이름을 선택했는가?”라고 질문한 다음 이를 문서화하십시오.
  • 이 문서에서 제공하는 지침과 차이가 있다면 사용자에게 알려야 합니다.
  • 가능하다면 최소한 기록을 위해 프로젝트의 버그 추적기에 이슈를 생성해야 합니다. 그러면 나중에 이를 해결하거나, 어쩌면 “wontfix”로 표시해도 됩니다.

커뮤니티의 기여를 받도록 의도된 프로젝트는 또한 Organize community contributions해야 합니다.

마이그레이션 장려

모든 Python 개발자는 가능한 경우 마이그레이션하거나 각자의 커뮤니티에서 마이그레이션을 장려해야 합니다.

이 가이드라인을 여러분의 프로젝트에 적용하면, 커뮤니티는 그것이 안전하다는 것을 알게 될 것입니다.

특히 인기 있는 프로젝트의 저자와 같은 “리더”들은 영향력이 있으며, 커뮤니티에 대해 힘을 가지고 있고, 따라서 책임도 가지고 있습니다.

이 가이드라인을 인기 있는 프로젝트에 적용하면, 커뮤니티들도 그 관례를 채택하게 될 것입니다.

프로젝트는 새로운 (메이저) 버전을 릴리스할 때 마이그레이션을 장려해야 합니다, 특히 이 버전이 Python 3.x 지원, 새로운 표준 라이브러리의 패키징 또는 네임스페이스 패키지를 도입하는 경우에 그렇습니다.

기회

Python 3.3이 개발되고 있는 현재:

  • 많은 프로젝트가 Python 3.x와 호환되지 않습니다. 여기에는 “대형” 제품이나 프레임워크도 포함됩니다. 이는 많은 프로젝트가 Python 3.x를 지원하기 위해 마이그레이션을 해야 한다는 것을 의미합니다.
  • 패키징(일명 distutils2)이 출발선에 서 있습니다. 이것이 릴리스되면, 프로젝트들은 마이그레이션하여 새로운 패키징을 사용하도록 권장될 것입니다.
  • PEP 420은 네임스페이스 패키지에 대한 공식 지원을 Python에 가져옵니다.

이는 대부분의 활성 프로젝트가 Python 3.x, 새로운 패키징 또는 새로운 네임스페이스 패키지를 지원하기 위해 향후 몇 년 안에 마이그레이션을 하게 될 것임을 의미합니다.

이러한 기회는 유일무이하며 다시 곧 오지 않을 것입니다! 따라서 가능한 한 빨리(즉 지금) 명명 규칙을 도입하고 장려합시다.

참고 문헌

추가 배경 정보:

참고 문헌 및 각주: