저는 Python으로 작업하기 시작했습니다. 내 프로젝트 에 requirements.txt
및 추가 setup.py
했습니다. 그러나 두 파일의 목적에 대해 여전히 혼란 스럽습니다. 나는 setup.py
재배포 가능한 것을 requirements.txt
위해 설계 되었고 재배포 불가능한 것을 위해 설계된 것을 읽었습니다 . 그러나 이것이 정확한지 확신하지 못합니다.
이 두 파일이 실제로 어떻게 사용되도록 의도 되었습니까?
저는 Python으로 작업하기 시작했습니다. 내 프로젝트 에 requirements.txt
및 추가 setup.py
했습니다. 그러나 두 파일의 목적에 대해 여전히 혼란 스럽습니다. 나는 setup.py
재배포 가능한 것을 requirements.txt
위해 설계 되었고 재배포 불가능한 것을 위해 설계된 것을 읽었습니다 . 그러나 이것이 정확한지 확신하지 못합니다.
이 두 파일이 실제로 어떻게 사용되도록 의도 되었습니까?
답변:
requirements.txt
이것은 개발 환경을 설정하는 데 도움이됩니다. 같은 프로그램을 pip
사용하여 파일에 나열된 모든 패키지를 한 번에 설치할 수 있습니다. 그 후에 파이썬 스크립트 개발을 시작할 수 있습니다. 다른 사람들이 개발에 기여하거나 가상 환경을 사용하도록 계획하는 경우 특히 유용합니다. 사용 방법은 다음과 같습니다.
pip install -r requirements.txt
setup.py
이를 통해 재배포 할 수있는 패키지를 만들 수 있습니다. 이 스크립트는 개발 환경을 준비하는 것이 아니라 최종 사용자의 시스템에 패키지를 설치하기위한 것 pip install -r requirements.txt
입니다. setup.py에 대한 자세한 내용 은 이 답변 을 참조하십시오.
프로젝트의 종속성은 두 파일에 모두 나열됩니다.
짧은 대답은 requirements.txt
패키지 요구 사항을 나열 하는 것입니다. setup.py
반면에 설치 스크립트와 비슷합니다. 파이썬 코드를 설치할 계획이 없다면 일반적으로requirements.txt
.
이 파일 setup.py
은 패키지 종속성 외에도 패키지화 (또는 네이티브 모듈의 경우 컴파일 (즉, C로 작성)의 경우 컴파일)해야하는 파일 및 모듈 세트와 파이썬 패키지 목록에 추가 할 메타 데이터 ( 예 : 패키지 이름, 패키지 버전, 패키지 설명, 작성자, ...).
두 파일 모두 종속성을 나열하기 때문에 약간의 중복이 발생할 수 있습니다. 자세한 내용은 아래를 참조하십시오.
requirements.txt
이 파일은 파이썬 패키지 요구 사항을 나열합니다. 파이썬 프로젝트 (한 줄에 하나씩) 의 패키지 종속성 을 나열하는 일반 텍스트 파일 (선택적으로 주석 포함)입니다 . 그것은 하지 않습니다 파이썬 패키지가 설치되는 방법을 설명합니다. 일반적으로 요구 사항 파일은 pip install -r requirements.txt
.
텍스트 파일의 파일 이름은 임의적이지만 일반적 requirements.txt
으로 일반적입니다. 다른 파이썬 패키지의 소스 코드 저장소를 탐색 할 때 dev-dependencies.txt
또는 같은 다른 이름을 우연히 발견 할 수 있습니다 dependencies-dev.txt
. 이들은 동일한 목적을 제공 dependencies.txt
하지만 일반적으로 특정 패키지의 개발자에게 관심있는 추가 종속성을 나열합니다. 즉, 릴리스 전에 소스 코드 (예 : pytest, pylint 등)를 테스트하기위한 것입니다. 일반적으로 패키지 사용자는 패키지를 실행하기 위해 전체 개발자 종속성 집합이 필요하지 않습니다.
여러 requirements-X.txt
변형이있는 경우 일반적으로 하나는 런타임 종속성을 나열하고 다른 하나는 빌드 시간 또는 테스트 종속성을 나열합니다. 일부 프로젝트는 또한 요구 사항 파일을 계단식으로 배열합니다 ( 예 : 하나의 요구 사항 파일에 다른 파일이 포함 된 경우 ) ( 예 ). 이렇게하면 반복을 줄일 수 있습니다.
setup.py
이것은 setuptools
모듈을 사용하여 파이썬 패키지 (이름, 포함 된 파일, 패키지 메타 데이터 및 설치)를 정의 하는 파이썬 스크립트입니다 . 와 마찬가지로 requirements.txt
패키지의 런타임 종속성도 나열합니다. Setuptools는 사실상 파이썬 패키지를 빌드하고 설치하는 방법이지만, 단점이 있습니다. 시간이 지남에 따라 pip와 같은 새로운 "메타 패키지 관리자"가 개발되었습니다. setuptools의 단점은 동일한 패키지의 여러 버전을 설치할 수없고 제거 명령이 없다는 것입니다.
파이썬 사용자가 pip install ./pkgdir_my_module
(또는 pip install my-module
)하면, pip는 setup.py
주어진 디렉토리 (또는 모듈)에서 실행 됩니다. 마찬가지로,가있는 모듈은 예를 들어 같은 폴더에서 실행 하여 설치할 setup.py
수 있습니다 .pip
pip install .
정말 둘 다 필요한가요?
짧은 대답은 '아니요'이지만 둘 다 갖는 것이 좋습니다. 서로 다른 목적을 달성하지만 둘 다 종속성을 나열하는 데 사용할 수 있습니다.
requirements.txt
과 사이의 종속성 목록이 중복되지 않도록 고려할 수있는 한 가지 트릭이 있습니다 setup.py
. setup.py
이미 완벽하게 작동 하는 패키지를 작성했고 종속성이 대부분 외부인 requirements.txt
경우 다음 만 사용하여 간단한 것을 고려할 수 있습니다 .
# requirements.txt
#
# installs dependencies from ./setup.py, and the package itself,
# in editable mode
-e .
# (the -e above is optional). you could also just install the package
# normally with just the line below (after uncommenting)
# .
은 -e
특별하다 pip install
에 주어진 패키지를 설치 옵션을 편집 모드. pip -r requirements.txt
이 파일에서이 실행 되면 pip는의 목록을 통해 종속성을 설치합니다 ./setup.py
. 편집 가능한 옵션은 설치 디렉토리 (에그 또는 아카이브 사본 대신)에 심볼릭 링크를 배치합니다. 개발자는 다시 설치하지 않고도 저장소에서 코드를 편집 할 수 있습니다.
패키지 저장소에 두 파일이 모두있는 경우 "setuptools extras"라는 기능을 활용할 수도 있습니다. 사용자 지정 범주 아래의 setup.py에서 선택적 패키지를 정의하고 pip를 사용하여 해당 범주에서만 해당 패키지를 설치할 수 있습니다.
# setup.py
from setuptools import setup
setup(
name="FOO"
...
extras_require = {
'dev': ['pylint'],
'build': ['requests']
}
...
)
그런 다음 요구 사항 파일에서 :
# install packages in the [build] category, from setup.py
# (path/to/mypkg is the directory where setup.py is)
-e path/to/mypkg[build]
이렇게하면 모든 종속성 목록이 setup.py에 보관됩니다.
참고 : 일반적으로 프로그램으로 만든 것과 같은 샌드 박스에서 pip 및 setup.py를 실행합니다 virtualenv
. 이렇게하면 프로젝트 개발 환경의 컨텍스트 외부에서 Python 패키지를 설치하는 것을 방지 할 수 있습니다.
.
w / o를 가질 수 있습니다 . 이 방법은 모든 요구 사항을 위임 할 뿐이며 누구에게도 편집 가능 모드로 전환 할 필요가 없습니다. 사용자는 원하는 경우 계속 할 수 있습니다 . -e
requirements.txt
setup.py
pip install -e .
-e .
또한 setup.py를 사용하여 종속성을 찾지 만 복사본을 가져 오는 대신 pip 설치 폴더에있는 현재 폴더 (심볼 링크와 함께)를 연결합니다. -e
일반적으로 패키지를 개발하는 경우에만 사용 합니다. 를 사용하면 -e
python 패키지 파일 (* .py)에 대한 변경 사항이 각 변경 후 패키지를 강제로 다시 설치하지 않고 pip 환경에서 즉시 적용됩니다.
cd foo && pip install -r ./bar/requirements.txt
할 경우 foo/bar
또는 에서 setup.py를 검색 foo
합니까? 후자의 경우 전자를 달성 할 수있는 방법이 있습니까?
pip -r REQ
REQ가있는 디렉토리는 신경 쓰지 않습니다. 원하는 경우에도 fifo에서 공급할 수 있습니다 pip install -r <(echo "mylib1"; echo "mylib2";)
. <(CMD)
stdin 리디렉션이 아닌 bash 명령 대체는 어디에 있습니까 ?
완벽을 위해, 나는 여기에서 그것을보고 어떻게 3 개 4 다른 각도.
다음은 공식 문서 에서 인용 한 정확한 설명입니다 (강조 표시).
install_requires (setup.py에 있음)는 단일 프로젝트에 대한 종속성 을 정의하는 반면 요구 사항 파일은 종종 완전한 Python 환경에 대한 요구 사항을 정의하는 데 사용됩니다. .
install_requires 요구 사항은 최소 수준이지만 요구 사항 파일에는 전체 환경의 반복 가능한 설치를 달성하기 위해 고정 된 버전의 전체 목록이 포함되는 경우가 많습니다.
그러나 여전히 이해하기 쉽지 않을 수 있으므로 다음 섹션에는 두 가지 접근 방식을 다르게 사용하는 방법을 보여주는 두 가지 사실적인 예가 있습니다.
따라서 실제 사용법은 다릅니다.
프로젝트 foo
가 독립형 라이브러리로 출시 될 예정 이라면 (다른 사람들은 아마도 그렇게 할 것입니다 import foo
), 당신 (그리고 당신의 다운 스트림 사용자들)은 유연한 의존성 선언을 원할 것입니다. 그래서 당신의 라이브러리는 그렇지 않을 것입니다. ) 종속성의 정확한 버전이 무엇인지 "선택적"이어야합니다. 따라서 일반적으로 setup.py에는 다음과 같은 행이 포함됩니다.
install_requires=[
'A>=1,<2',
'B>=2'
]
애플리케이션에 대해 정확한 현재 환경을 "문서화"하거나 "고정"하려는 경우 bar
, 즉, 귀하 또는 귀하의 사용자가 애플리케이션을있는 bar
그대로 사용하기를 python bar.py
원할 경우 (예 : 실행 중 ) 환경을 고정하여 항상 동일하게 작동합니다. 이 경우 요구 사항 파일은 다음과 같습니다.
A==1.2.3
B==2.3.4
# It could even contain some dependencies NOT strickly required by your library
pylint==3.4.5
실제로 어떤 것을 사용합니까?
에서 bar
사용할 응용 프로그램 을 개발하는 python bar.py
경우 "재미 용 스크립트"라하더라도 requirements.txt를 사용하는 것이 좋습니다. 다음 주 (크리스마스가 될 때)에 다음 주에 새 컴퓨터를 선물로 사용하려면 정확한 환경을 다시 설정해야합니다.
에서 foo
사용할 라이브러리 를 개발하는 경우import foo
setup.py를 준비해야합니다. 기간. 그러나 여전히 requirements.txt를 동시에 제공하도록 선택할 수 있습니다.
(a) A==1.2.3
위의 # 2에서 설명한대로 스타일 .
(b) 또는 마법의 싱글을 포함 .
.
중복없이 "setup.py를 기반으로 요구 사항을 설치"하는 것과 거의 같습니다. 개인적으로 저는이 마지막 접근 방식이 선을 흐리게하고 혼란을 가중시키고 실제로 가치를 추가하지 않는다고 생각하지만 그럼에도 불구하고 그의 블로그 게시물 에서 Python 패키징 관리자 Donald가 언급 한 접근 방식에서 파생 된 트릭 입니다.
다른 하한.
당신은 세 기준 이상으로 다음과 제대로 라이브러리가 결정 후에도 hybrid-engine
을 사용 setup.py
의존성을 선언 engine>=1.2.0
하고 샘플 응용 프로그램을 reliable-car
사용하는 것이 requirements.txt
의존성을 선언하는 engine>=1.2.3
최신 버전의에도 불구하고, engine
1.4.0에서 이미. 보시다시피 하한 수에 대한 선택은 여전히 미묘하게 다릅니다. 그리고 여기에 그 이유가 있습니다.
hybrid-engine
에 따라 engine>=1.2.0
가설 적으로 말하기 때문에, 필요한 "내연"기능을 처음으로 도입 engine 1.2.0
하고, 그 능력의 필요성이다 hybrid-engine
상관없이 같은 버전 내부의 (작은) 버그가있을 수 있습니다 여부 및 후속 버전 1.2.1에서 수정되었습니다 , 1.2.2 및 1.2.3.
reliable-car
engine>=1.2.3
현재까지 알려진 문제가없는 가장 초기 버전이기 때문에에 의존합니다 . 물론에서 도입 된 "전기 모터" engine 1.3.0
와 에서 도입 된 "원자력로"와 같은 최신 버전에는 새로운 기능이 engine 1.4.0
있지만 프로젝트에는 필요하지 않습니다 reliable-car
.
A==1.2.3
라이브러리의 다운 스트림 패키지가에 의존하는 A==1.2.4
경우 이제 둘 다 충족 할 수있는 방법이 없습니다. 이 충돌을 최소화하는 해결책은 라이브러리가 작동 할 것으로 알고있는 범위를 정의하는 것입니다. 다음 이미 많은 상류 라이브러리를 가정 semver.org을 , A>=1,<2
작동합니다.
foo
않습니다 import foo
당신을 줄? 그 해키는 대답을 받아 들였습니다.당신이 제공 한 링크 은 왜 패키지 관리자가 "까다로워서는 안되고 까다로워서는 안되는"이유에 대한 완벽한 예입니다. :-) 이제 당신의 찬성 투표를 할 수 있습니까?