requirements.txt 대 setup.py

requirements.txt 대 setup.py

---

저는 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로 작성)의 경우 컴파일)되어야하는 파일 및 모듈 세트와 Python 패키지 목록에 추가 할 메타 데이터 ( 예 : 패키지 이름, 패키지 버전, 패키지 설명, 작성자 등).

두 파일 모두 종속성을 나열하기 때문에 약간의 중복이 발생할 수 있습니다. 자세한 내용은 아래를 참조하십시오.

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 내에 유지됩니다.

Note: You would normally execute pip and setup.py from a sandbox, such as those created with the program virtualenv. This will avoid installing python packages outside the context of your project's development environment.

---

For the sake of completeness, here is how I see it in 3 different angles.

1. Their design purposes are different

This is the precise description quoted from the official documentation (emphasis mine):

Whereas install_requires (in setup.py) defines the dependencies for a single project, Requirements Files are often used to define the requirements for a complete Python environment.

Whereas install_requires requirements are minimal, requirements files often contain an exhaustive listing of pinned versions for the purpose of achieving repeatable installations of a complete environment.

But it might still not easy to be understood, so in next section, there come 2 factual examples to demonstrate how the 2 approaches are supposed to be used, differently.

2. Their actual usages are therefore (supposed to be) different

   • If your project foo is going to be released as a standalone library (meaning, others would probably do import foo), then you (and your downstream users) would want to have a flexible declaration of dependency, so that your library would not (and it must not) be "picky" about what exact version of YOUR dependencies should be. So, typically, your setup.py would contain lines like this:

     install_requires=[
         'A>=1,<2',
         'B>=2'
     ]
     

   • If you just want to somehow "document" or "pin" your EXACT current environment for your application bar, meaning, you or your users would like to use your application bar as-is, i.e. running python bar.py, you may want to freeze your environment so that it would always behave the same. In such case, your requirements file would look like this:

     A==1.2.3
     B==2.3.4
     # It could even contain some dependencies NOT strickly required by your library
     pylint==3.4.5
     

3. In reality, which one do I use?

   • If you are developing an application bar which will be used by python bar.py, even if that is "just script for fun", you are still recommended to use requirements.txt because, who knows, next week (which happens to be Christmas) you would receive a new computer as a gift, so you would need to setup your exact environment there again.

   • If you are developing a library foo which will be used by import foo, you have to prepare a setup.py. Period. But you may still choose to also provide a requirements.txt at the same time, which can:

     (a) either be in the A==1.2.3 style (as explained in #2 above);

     (b) or just contain a magical single .

     .
     

     which would roughly equal to "install the requirements based on setup.py" while without duplication. Personally I consider this last approach kind of blurs the line, adds to the confusion and does NOT really add value, but it is nonetheless a trick derived from an approach mentioned by Python packaging maintainer Donald in his blog post.

참고URL : https://stackoverflow.com/questions/43658870/requirements-txt-vs-setup-py