Documentation for a newer release is available. View Latest

파이썬

Setuptools 59

페도라 리눅스 36는 python-setuptools_ 59를 제공합니다. 이는 use_2to3 setup 명령의 제거를 포함합니다. 더 자세한 정보는, 업스트림 변경기록을 참고하세요.

파이썬 꾸러미의 신규 설치 계획

페도라 리눅스 36에서, 파이썬은 파이썬 꾸러미의 설치 경로가 처리되는 방식을 변경합니다. 이들 변경은 페도라 36에서 주 파이썬, 파이썬 3.10뿐만 아니라 신규 파이썬이 포함된 버전에 영향을 미칩니다. 대부분페도라 리눅스 사용자는 변경에 의해 영향을 받지 않으나 약간의 차이가 있을 수 있습니다.

파이썬 꾸러미가 sudo pip, sudo python setup.py install 또는 유사한 방식에 의해 설치되었을 때에, 파이썬 꾸러미는 `/usr/local/lib(64)/python3.10/site-packages/`로 설치됩니다. 이는 이미 페도라 리눅스 27 이후 발생되어 설치되었습니다. 아무튼 이와 같이 저장된 방식은 페도라 리눅스 36에서 크게 재-구현되었고 이는 몇 가지 사소한 차이점을 만들었습니다.

표준 라이브러리에서 sysconfig 파이썬 모듈은 몇 가지 *설치 계획*을 정의합니다. 기본적으로, root 권한(예: `sudo`를 통해)을 사용하여 파이썬 꾸러미를 설치 할 때에 페도라 36에서 사용되는 설치 계획은 `{prefix}/lib(64)/python3.10/site-packages/`이고, 여기서 `{prefix }`는 기본적으로 `/usr/local`로 정의됩니다. RPM 꾸러미를 제작 할 때에, `{prefix}`는 기본적으로 `/usr`로 정의됩니다. 파이썬 자체적으로 파이썬 가상 환경에서 동작 할 때에, `{prefix}`는 가상 환경을 위한 경로로 지정됩니다.

이전에, /local/ 부분은 `distutils`를 통해 꾸러미를 설치 할 때 인위적으로 추가되었지만, 이제 `sysconfig`에서도 정의 될 수 있습니다. 이는 다른 파이썬 배포자가 수행하는 작업과 보다 일관성이 있도록 변경되었으며, 스키마는 업스트림 파이썬에서 보다 잘 수용되고, setuptools 또는 pip와 같은 업스트림 도구와 잘 작동하며, 이 도구는 파이썬 꾸러미 색인에서 직접 pip를 사용하여 설치 될 때 또는 향상 할 때에 수정 할 수 없습니다.

다음과 같은 신규 접근으로 관찰되는 차이점입니다:

`sysconfig.get_path(key)`는 `/local/`로 경로를 반환합니다

이전, 가상 환경 밖의 페도라 리눅스 35에서:

>>> import sysconfig
>>> for key in sysconfig.get_path_names():
...     print(f'{key} = {sysconfig.get_path(key)}')
...
stdlib = /usr/lib64/python3.10
platstdlib = /usr/lib64/python3.10
purelib = /usr/lib/python3.10/site-packages
platlib = /usr/lib64/python3.10/site-packages
include = /usr/include/python3.10
scripts = /usr/bin
data = /usr

이제, 페도라 리눅스 36에서 (RPM 제작 중 제외):

>>> import sysconfig
>>> for key in sysconfig.get_path_names():
...     print(f'{key} = {sysconfig.get_path(key)}')
...
stdlib = /usr/lib64/python3.10
platstdlib = /usr/lib64/python3.10
purelib = /usr/local/lib/python3.10/site-packages
platlib = /usr/local/lib64/python3.10/site-packages
include = /usr/include/python3.10
scripts = /usr/local/bin
data = /usr/local

값은 이제 꾸러미가 pip, setuptools, distutils 등과 함께 설치 될 때에 실제 위치의 현실을 반영합니다. 아무튼, 만약 자신의 파이썬 코드가 값을 사용하여 파이썬 꾸러미 *from*을 적재 할 위치를 결정하는 경우에, dnf-설치된 꾸러미가 표시되지 않으며, 이는 `/usr/lib(64)/python3.10/site-packages/`에 설치됩니다. 일반적으로, `sysconfig.get_path(key)`는 파이썬 꾸러미가 *to*로 설치되어야 하는 위치를 결정하는 결과를 제공합니다. 영향을 받는 코드를 수정하려면, "꾸러미 *to*를 설치할 위치"가 파이썬 모듈 *from*을 적재 할 위치"와 동일하다는 가정을 피하세요.

영향을 미치는 개방형 원천 프로젝트에서 수정된 예시:

만약 당신이 sysconfig.get_path(key)`의 이전 행위를 복구 하려면, 당신은 `{base}`와 `{platbase} 변수를 `/usr`로 명시적으로 설정해야 합니다:

>>> for key in sysconfig.get_path_names():
...     print(f'{key} = {sysconfig.get_path(key, vars={"base": "/usr", "platbase": "/usr"})}')
...
stdlib = /usr/lib64/python3.10
platstdlib = /usr/lib64/python3.10
purelib = /usr/lib/python3.10/site-packages
platlib = /usr/lib64/python3.10/site-packages
include = /usr/include/python3.10
scripts = /usr/bin
data = /usr

RPM build–관련 주의 사항

파이썬이 RPM 제작 중에 동작 할 때, 이는 {base} 과 {platbase} 변수의 기본값을 /usr`로 설정합니다. 이와 같은 행위는 `$RPM_BUILD_ROOT 환경 변수가 설정 될 때에 진행됩니다. 다음과 같은 몇 가지 주의 사항을 가집니다:

파이썬 하위-프로세서에서 파이썬 실행하기

만약 RPM 제작(예제로 %check)에서 실행되는 파이썬 코드가 하위 프로세스를 통해 다른 파이썬 예를 실행하는 경우, 모든 환경 변수를 무심코 설정 해제하기가 상대적으로 쉽습니다.이와 같은 발생하면, 내부 파이썬은 RPM 제작에서 실행되는 것을 알지 못하고 /usr/local/ 접두사가 있는 경로를 반환합니다.

가장 사소한 예제에서, 주위 환경 변수는 암묵적으로 하위프로세스에 전달되고 모든 것은 다음과 같이 예상된 대로 동작합니다:

>>> import os, subprocess, sys
>>> 'RPM_BUILD_ROOT' in os.environ
True
>>> command = [sys.executable, '-c', 'import sysconfig; print(sysconfig.get_path("purelib"))']
>>> subprocess.check_output(command)
b'/usr/lib/python3.10/site-packages\n'

그러나 사용자 정의 환경이 전달될 때 `$RPM_BUILD_ROOT`가 더 이상 설정되지 않기 때문에 탐지가 중단됩니다:

>>> subprocess.check_output(command, env={'FOO': 'bar'})
b'/usr/local/lib/python3.10/site-packages\n'

해결방법은 항상 주변 환경의 복사본을 만들고, 그런 후에 이를 편집하고, 하위 처리에 전달하는 것입니다. 이는 일반적으로 유효한 파이썬 조언입니다.

>>> env = os.environ | {'FOO': 'bar'}
>>> subprocess.check_output(command, env=env)
b'/usr/lib/python3.10/site-packages\n'

영향을 미치는 개방형 원천 프로젝트에서 수정된 예시:

%(…​) RPM 매크로

%(command …​) 형식의 RPM 매크로를 확장할 때에, `$RPM_BUILD_ROOT`는 아직 설정되지 않았습니다. 그러므로, 파이썬은 RPM 제작에서 호출되고 `sysconfig.get_path(…​)`에 의해 반환된 경로는 `/local/`이 포함되어 있다는 것을 알지 못합니다. 이를 해결하려면, 매크로 정의(심지어 비워 있는 경우, 임의 값으로)에서 `$RPM_BUILD_ROOT`를 설정합니다. 예를 들면 매크로는 이와 같이 정의됩니다:

%global python3_scripts_dir %(python3 "import sysconfig; print(sysconfig.get_path('scripts'))")

이와 같이 변경되어야 합니다:

%global python3_scripts_dir %(RPM_BUILD_ROOT= python3 "import sysconfig; print(sysconfig.get_path('scripts'))")

페도라의 python-rpm-macros 꾸러미에서 제공되는 영향을 받는 RPM 매크로가 모두 그에 따라 변경되었습니다.

부트스트랩핑 파이썬 가상 환경을 위한 경로

만약 자신의 파이썬 코드가 설치 체계를 사용하여, 생성된 가상 환경에서 사용 할 경로를 결정하고, 해당 코드를 실행하는 파이썬 인터프리터가 파이썬 가상 환경 자체에서 실행되지 않는 경우, 경로가 일치하지 않습니다.

파이썬 가상 환경을 부트스트랩 하려면, 코드는 venv 설치 체계를 사용해야 합니다 (만약 이게 존재 한다면).

>>> scheme = 'venv' if 'venv' in sysconfig.get_scheme_names() else None
>>> sysconfig.get_path('purelib', scheme=scheme, vars={'base': '<venv>'})
'<venv>/lib/python3.10/site-packages'
>>> sysconfig.get_path('scripts', scheme=scheme, vars={'base': '<venv>'})
'<venv>/bin'

venv 계획는 현재 페도라로 지정되지만, 다른 파이썬 배포자(예: 우분투 Deadsnakes와 같은)도 이를 정의 할 수 있습니다. venv 계획는 일반적으로 파이썬 3.11부터 사용 할 수 있습니다. 만약 venv 설치 계획이 존재하는지 확인하기 때문에 이 코드는 이전 버전과 호환되는 동작으로 대체되므로 다른 운영 체제에서도 작동합니다.

영향을 미치는 개방형 원천 프로젝트에서 수정된 예시:

Django 4.0

페도라 리눅스 36는 Django 4.0의 최신 버전을 제공합니다. 이와 같은 버전의 몇 가지 강조 사항은 다음과 같습니다:

  • 신규 RedisCache 백엔드는 Redis와 같은 캐슁을 위해 내장된 지원을 제공합니다.

  • Forms, Formsets과 ErrorList의 사용자 정의를 쉽게 하려면, 이들은 이제 템플릿 엔진을 사용하여 렌더링됩니다.

  • 파이썬 표준 라이브러리의 영역정보는 이제 Django에서 기본값 시간대 구현입니다.

더 상세한 정보를 위해, 업스트림 출시 기록을 참고하세요.

Want to help? Learn how to contribute to Fedora Docs ›