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

개요

다음은 이름을 선택할 때 따라야 할 지침을 요약한 목록입니다:

확신이 서지 않으면 문의하십시오

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

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

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

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

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

소유권을 존중하십시오

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

명시적으로 허가받지 않았다면 여러분이 소유하지 않은 네임스페이스에 끼어들지 마십시오.

If in doubt, ask.

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

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

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

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

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

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

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

이 규칙은 클로즈드 소스 프로젝트에 적용됩니다.

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

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

… 개인 프로젝트는 개인이 소유하고 있기 때문입니다. 따라서 소유권 규칙을 적용하십시오.

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

작성자가 소유권을 바꾸고 싶은 시점이 오면(즉, 프로젝트가 더 이상 개인에게 속하지 않게 되면), 프로젝트 이름을 쉽게 바꿀 수 있다는 점을 기억하십시오.

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

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

코드를 정말로 커뮤니티 소유로 만들 의도가 있을 때에만 “공유” 네임스페이스를 사용하십시오.

예를 들어 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의 고유 식별자로 간주하십시오:

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

분류자(classifier)와 키워드 메타데이터는 배포 패키지를 분류하기 위해 만들어졌습니다. 요약과 설명 메타데이터는 프로젝트를 설명하기 위한 것입니다.

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

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

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

  • plone.portlet.*
  • collective.portlet.*
  • collective.portlets.*
  • collective.*.portlets
  • “quintagroup.portlet.cumulus”와 같은 일부 벤더 관련 프로젝트
  • 그리고 이름에 “portlet” 패턴이 아예 나타나지 않는 프로젝트까지

Plone 커뮤니티에 관례가 있더라도, 이름으로 배포 패키지를 분류하는 것은 적절하지 않습니다. 이름으로 필터링해서는 Plone용 포틀릿을 제공하는 배포 패키지의 전체 목록을 얻을 수 없습니다. 하지만 이 배포판들이 모두 “Framework :: Plone” 분류자와 “portlet” 키워드를 사용한다면 가능할 것입니다(Plone 프레임워크 분류자).

깊은 중첩을 피하십시오

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

거의 항상 두 단계면 충분합니다

모든 것을 깊이 중첩된 계층 구조로 정의하지 마십시오. 그렇게 하면 결국 “pythonsport.common.maps.forest”와 같은 프로젝트와 패키지가 만들어집니다. 이런 유형의 이름은 장황하고 번거롭습니다(예를 들어 해당 패키지에서 많은 것을 임포트하는 경우).

게다가 서로 다른 패키지 사이의 경계가 흐려지면서 큰 계층 구조는 시간이 지남에 따라 무너지는 경향이 있습니다.

두 단계의 중첩이 바람직하다는 것이 공통된 의견입니다.

예를 들어, plone.source.principal 같은 이름 대신 plone.principalsource를 사용합니다. 이름은 더 짧고 패키지 구조는 더 단순하며, 여기서 세 단계의 중첩을 두어 얻을 수 있는 이점은 거의 없습니다. 모든 “핵심 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”에서 착안한 것입니다.

커뮤니티 기여 구성하기

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

조치:

  • 커뮤니티 기여를 위한 명명 관례를 선택하십시오.
  • 그것이 기본값이 아니라면 문서화하십시오.
    • 기본 관례를 사용한다면 이 문서로 충분할 것입니다. 그 내용을 반복하지 마십시오. 이 문서를 참조해도 됩니다.
    • 그렇지 않으면 프로젝트의 “기여하기” 또는 “모듈 만들기” 문서에서 사용자에게 자체 규칙을 알리십시오.
  • 또한 분류자와 키워드 같은 추가 메타데이터를 사용하도록 권장하십시오.

관례 선택에 관하여:

  • 새 프로젝트는 기본 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가 중요합니다.

또한 배포된 패키지나 모듈의 이름이 이미 등록되어 있지 않은지 확인하십시오:

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

프로젝트 이름은 어떻게 바꿉니까?

프로젝트 이름을 바꾸는 것은 가능하지만, 어느 정도 혼란을 일으킨다는 점을 명심하십시오. 따라서 사용자가 무슨 일이 있었는지 이해할 수 있도록 README와 문서에 특히 주의를 기울이십시오.

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

이렇게 하면 기존 패키지의 사용자는:

  • 사용 중단된 버전의 레거시 배포판을 계속 사용할 수 있습니다.
  • 내용이 비어 있는 레거시 배포판의 마지막 버전으로 업그레이드할 수 있습니다…
  • … 그리고 레거시 배포판의 의존성으로 새 배포판을 자동으로 내려받습니다.

레거시 프로젝트를 발견한 사용자는 그 프로젝트가 비활성 상태임을 알 수 있습니다.

PyPI에서 이름이 바뀐 프로젝트의 처리 개선

많은 프로젝트가 이름 변경 방법에 나온 절차를 따른다면, 많은 레거시 배포판은 다음과 같은 특징을 갖게 됩니다:

  • Development Status :: 7 - Inactive 분류자가 지정되어 있습니다.
  • 최신 버전은 패키징 관련 내용을 제외하면 비어 있습니다.
  • 최신 버전은 다른 배포판으로 “리다이렉트”합니다. 예를 들어, 이름이 바뀐 프로젝트에 대한 의존성 하나만 가집니다.
  • 더 새로운 배포판에서 Obsoletes-Dist로 참조됩니다.

따라서 이름이 바뀐 프로젝트를 감지하여 PyPI에서의 가독성을 개선할 수 있을 것입니다. 그렇게 하면 사용자는 활성 상태인 배포판에 집중할 수 있습니다. 하지만 이 기능은 지금 당장 필요하지는 않습니다. 서두를 필요가 없습니다. 이 문서에서는 다루지 않습니다.

기존 프로젝트에 이름 짓기 지침을 어떻게 적용합니까?

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

다만 프로젝트 작성자에게 다음을 권합니다:

현재 이름에 대해 밝히기

우선 중요한 것은 현재의 선택에 대해 밝히는 것입니다:

  • “왜 현재 이름을 선택했는가?”라고 스스로 물어본 다음, 그 내용을 문서화하십시오.
  • 이 문서에서 제공하는 지침과 차이가 있다면, 사용자에게 알려야 합니다.
  • 가능하다면, 최소한 기록을 위해서라도 프로젝트의 버그 트래커에 이슈를 만드십시오. 그러면 나중에 자유롭게 해결하거나, “wontfix”로 표시할 수도 있습니다.

커뮤니티로부터 기여를 받고자 하는 프로젝트는 또한 커뮤니티 기여를 체계화해야 합니다.

마이그레이션 장려하기

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

여러분의 프로젝트에 이 지침을 적용하십시오. 그러면 커뮤니티가 이 지침이 안전하다는 것을 알게 될 것입니다.

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

인기 있는 프로젝트에 이 지침을 적용하십시오. 그러면 커뮤니티도 이 관례를 받아들일 것입니다.

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

기회

Python 3.3이 개발 중인 현재 상황은 다음과 같습니다:

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

이는 대부분의 활발한 프로젝트가 Python 3.x, 새 패키징 또는 새 네임스페이스 패키지를 지원하기 위해 향후 1~2년 안에 이전하게 될 것임을 의미합니다.

이런 기회는 흔치 않으며 곧 다시 오지 않을 것입니다! 그러니 가능한 한 빨리(즉, 지금) 이름 짓기 관례를 도입하고 장려합시다.

참고 문헌

추가 배경 자료:

참고 문헌 및 각주: