[Withdrawn] PEP 243 - Module Repository Upload Mechanism

원문 링크: PEP 243 - Module Repository Upload Mechanism

상태: Withdrawn 유형: Standards Track 작성일: 18-Mar-2001

PEP 243 – 모듈 저장소 업로드 메커니즘 번역 및 요약

이 문서는 Python Enhancement Proposal (PEP) 243, “모듈 저장소 업로드 메커니즘”에 대한 한국어 번역 및 요약본입니다. 이 PEP는 Python 모듈 저장소(예: Perl의 CPAN)에 모듈을 쉽게 제출할 수 있는 메커니즘을 제안합니다.

개요 (Abstract)

성공적인 모듈 저장소 시스템(예: Perl의 CPAN)을 위해서는 모듈 저자가 자신의 작업을 제출하는 과정이 가능한 한 쉬워야 합니다. 이 제출 과정은 배포 아카이브가 성공적으로 생성된 후 Distutils 도구 내에서 이루어지는 것이 자연스럽습니다. 예를 들어, 모듈 저자가 setup.py sdist의 결과를 확인하여 소프트웨어를 테스트한 후, setup.py sdist --submit 명령을 입력할 수 있습니다. 이 명령은 Distutils에 소스 배포판을 아카이브 서버로 제출하여 미러에 포함 및 배포하도록 지시합니다.

이 PEP는 소프트웨어 배포판을 아카이브에 제출하는 메커니즘만을 다루며, 실제 아카이브/카탈로그 서버 자체는 다루지 않습니다.

업로드 프로세스 (Upload Process)

업로드에는 Distutils PKG-INFO 메타데이터 정보(PEP 241에 명시된 대로), 실제 소프트웨어 배포판, 그리고 기타 선택적 정보가 포함됩니다. 이 정보는 일반적인 HTML 파일 업로드 요청과 동일하게 multi-part form으로 인코딩되어 업로드됩니다. 이 폼은 ENCTYPE="multipart/form-data" 인코딩(RFC 1867)을 사용하여 전송됩니다.

업로드는 “www.python.org” 호스트의 80/tcp 포트(POST http://www.python.org:80/pypi)로 이루어집니다. 폼은 다음 필드로 구성됩니다:

  • distribution: 모듈 소프트웨어를 포함하는 파일(예: .tar.gz 또는 .zip 파일)입니다.
  • distmd5sum: 업로드된 배포판의 MD5 해시입니다. 다이제스트의 16진수 표현을 나타내는 ASCII로 인코딩됩니다.
  • pkginfo (선택 사항): 배포판 메타데이터를 포함하는 파일(PEP 241에 명시된 대로)입니다. 이 필드가 포함되지 않으면, 배포 파일은 .tar (gzipped 및 bzipped 압축 허용) 또는 .zip 형식이며, 최상위 디렉토리(예: package-1.00/PKG-INFO)에 PKG-INFO 파일이 있어야 합니다.
  • infomd5sum (pkginfo 필드가 있는 경우 필수): 업로드된 메타데이터의 MD5 해시입니다. 다이제스트의 16진수 표현을 나타내는 ASCII로 인코딩됩니다.
  • platform (선택 사항): 이 배포판의 대상 플랫폼을 나타내는 문자열입니다. 이는 바이너리 배포판에만 해당됩니다. <os_name>-<os_version>-<platform architecture>-<python version> 형식으로 인코딩됩니다.
  • signature (선택 사항): 저자가 서명한 업로드된 배포판의 OpenPGP 호환 서명입니다. 이는 카탈로그 시스템이 업로드 승인을 자동화하는 데 사용될 수 있습니다.
  • protocol_version: 클라이언트가 지원하는 프로토콜 버전을 나타내는 문자열입니다. 이 문서는 프로토콜 버전 “1”을 설명합니다.

반환 데이터 (Return Data)

업로드 상태는 HTTP 비표준(X-*) 헤더를 사용하여 보고됩니다. X-Swalow-Status 헤더는 다음 값을 가질 수 있습니다:

  • SUCCESS: 업로드가 성공했음을 나타냅니다.
  • FAILURE: 어떤 이유로든 업로드를 처리할 수 없음을 나타냅니다.
  • TRYAGAIN: 서버가 현재 업로드를 수락할 수 없지만, 클라이언트는 나중에 다시 시도해야 함을 나타냅니다. 잠재적인 원인으로는 서버의 리소스 부족, 관리자 다운타임 등이 있습니다.

선택적으로, X-Swalow-Reason 헤더가 있을 수 있으며, 이는 X-Swalow-Status에 대한 더 자세한 정보를 제공하는 사람이 읽을 수 있는 문자열을 포함합니다.

X-Swalow-Status 헤더가 없거나 위에 언급된 세 문자열 중 하나를 포함하지 않는 경우, 일시적인 실패로 처리되어야 합니다.

예시:

>>> f = urllib.urlopen('http://www.python.org:80/pypi')
>>> s = f.headers['x-swalow-status']
>>> s = s + ': ' + f.headers.get('x-swalow-reason', '<None>')
>>> print s
FAILURE: Required field "distribution" missing.

샘플 폼 (Sample Form)

업로드 클라이언트는 다음 폼이 주어졌을 때 Linux용 Netscape Navigator 버전 4.76이 생성하는 것과 동일한 형태로 페이지를 제출해야 합니다.

<H1>Upload file</H1>
<FORM NAME="fileupload" METHOD="POST" ACTION="pypi" ENCTYPE="multipart/form-data">
<INPUT TYPE="file" NAME="distribution"><BR>
<INPUT TYPE="text" NAME="distmd5sum"><BR>
<INPUT TYPE="file" NAME="pkginfo"><BR>
<INPUT TYPE="text" NAME="infomd5sum"><BR>
<INPUT TYPE="text" NAME="platform"><BR>
<INPUT TYPE="text" NAME="signature"><BR>
<INPUT TYPE="hidden" NAME="protocol_version" VALUE="1"><BR>
<INPUT TYPE="SUBMIT" VALUE="Upload">
</FORM>

플랫폼 (Platforms)

다음은 유효한 OS 이름입니다:

aix, beos, debian, dos, freebsd, hpux, mac, macos, mandrake, netbsd, openbsd, qnx, redhat, solaris, suse, windows, yellowdog

위 목록에는 여러 다른 유형의 Linux 배포판이 포함됩니다. 버전 문제로 인해 이들을 분리해야 하며, 한 시스템이 다른 유사한 시스템에서 만들어진 배포판을 사용하는 것이 합리적일 때 다운로드 클라이언트가 구별할 것으로 예상됩니다.

Version은 특정 릴리스에 대해 벤더가 지정한 공식 버전 문자열입니다. 예를 들어, “2000” 및 “nt” (Windows), “9.04” (HP-UX), “7.0” (RedHat, Mandrake) 등이 있습니다.

다음은 유효한 아키텍처입니다:

alpha, hppa, ix86, powerpc, sparc, ultrasparc

현황 (Status)

현재 개념 증명(proof-of-concept) 클라이언트와 서버가 구현되어 있습니다. Distutils 패치는 2.1 릴리스에 맞춰 준비될 계획이었습니다. Andrew의 PEP 241(배포 메타데이터 지정)과 결합하여, 2.2 릴리스를 위한 카탈로그 시스템을 확정하기 위한 실제 데이터를 수집할 수 있는 플랫폼을 확보하기를 희망했습니다.

참고: 이 PEP는 최종적으로 Withdrawn 상태가 되었습니다. 즉, 이 제안은 철회되었으며 Python의 표준으로 채택되지 않았습니다. 이는 현대의 PyPI (Python Package Index) 및 twine과 같은 업로드 도구는 이 PEP에 명시된 방식과는 다른 진화된 메커니즘을 사용하고 있음을 의미합니다.

이 문서는 퍼블릭 도메인에 공개되었습니다.

⚠️ 알림: 이 문서는 AI를 활용하여 번역되었으며, 기술적 정확성을 보장하지 않습니다. 정확한 내용은 반드시 원문을 확인하시기 바랍니다.

Comments