긴 이야기 짧게

긴 이야기 짧게

Python 패키지는 종종 많은 배포판의 저장소에서 호스팅됩니다. 읽고 나서이것튜토리얼, 특히 "정말로 이 작업을 하시겠습니까?"라는 제목의 섹션에서는 pip 사용을 피하고 시스템 저장소를 사용하는 것을 선호했으며 저장소에 없는 패키지를 설치해야 할 때만 pip를 사용했습니다.

하지만 이는 일관성이 없는 설치 방법이므로 그냥 pip를 사용하는 것이 좋을까요? 두 곳에서 모두 사용할 수 있는 패키지에 대해 시스템 자체 저장소 대신 pip를 사용하면 어떤 이점/단점이 있습니까?

링크 상태를 포함했습니다

항상 표준 Debian/NeuroDebian 패키지를 사용하는 이점은 이러한 패키지가 서로 호환성을 보장하기 위해 신중하게 테스트된다는 것입니다. 데비안 패키지는 다른 라이브러리에 대한 종속성을 문서화하므로 설치 중에 필요한 라이브러리를 항상 얻을 수 있습니다.

나는 아치를 사용합니다. apt 외에도 다른 패키지 관리 시스템에서도 마찬가지인가요?

답변1

내 생각에 Python 모듈(시스템 모듈이든 사용자 모듈이든)을 사용하여 시스템에 설치할 때의 가장 큰 단점은 pip배포판의 패키지 관리 시스템이 이에 대해 알지 못한다는 것입니다. 즉, 이를 필요로 하는 다른 패키지에서는 사용되지 않으며 나중에 설치하려고 할 수도 있습니다(또는 업그레이드 후 모듈 중 하나를 사용하기 시작할 수도 있습니다). 그러면 pip두 모듈의 릴리스 관리가 종료됩니다. 문제를 일으킬 수 있는 버전(나는이런 예가 또 있다최근의). 따라서 귀하의 질문은 궁극적으로 전부 아니면 전무의 제안입니다.오직Python 모듈 의 경우 pipPython 모듈을 사용하려는 모든 것에 대해 더 이상 배포판의 패키지 관리자를 사용할 수 없습니다...

귀하가 링크한 페이지에 제공된 일반적인 조언은 매우 좋습니다. 가능할 때마다 배포판 패키지를 pip패키지되지 않은 모듈에 대해서만 사용하고, 그렇게 하는 경우 시스템 전체가 아닌 사용자 설정에서 그렇게 하십시오. 특히 모듈 개발의 경우 가능하면 가상 환경을 사용하십시오. 특히 아치에서는 문제가 될 수 있는 배포판에서도 오래된 모듈로 인해 발생하는 문제가 발생해서는 안 됩니다. 가상 환경에서는 이를 쉽게 처리할 수 있습니다.

배포판의 라이브러리와 모듈 패키지가 주로 배포판의 다른 패키지에서 사용하기 위해 패키지된다는 점을 고려하는 것은 가치가 있습니다. 이러한 패키지를 갖는 것은 해당 라이브러리와 모듈을 사용하여 개발하는 데 따른 좋은 부작용이지만 이것이 주요 사용 사례는 아닙니다.

답변2

긴 이야기 짧게

  • pip물건(라이브러리, 프레임워크, 개발 도구)에는 (+ virtualenv)를 사용하세요 .당신의 프로젝트(귀하가 개발) 사용
  • 애플리케이션의 패키지 관리자 사용사용(최종 사용자로)

개발 종속성

pipPython으로 소프트웨어를 개발하는 경우 런타임 종속성, 빌드 시간 종속성 또는 자동화된 테스트 및 자동화된 규정 준수 확인에 필요한 항목(린터, 스타일 검사기, 정적 유형 검사기) 등 프로젝트의 모든 종속성을 사용해야 합니다 . ...)

몇 가지 이유가 있습니다:

  • 이를 통해 다음을 사용할 수 있습니다.가상 환경서로 다른 프로젝트의 종속성을 서로 분리하고(직접 또는 virtualenvwrapper 또는 Pipenv 등을 통해) "프로덕션에서"(사용자로서) 사용하는 Python 애플리케이션을 가능한 외계인 장난(또는 단순히 비호환성)으로부터 격리합니다. 계속해서 발전하세요.
  • requirements.txt이를 통해 파일 (프로젝트가 애플리케이션인 경우) 또는 (프로젝트가 라이브러리 또는 프레임워크인 경우) setup.py에서 프로젝트의 모든 종속성을 추적할 수 있습니다. 이를 소스 코드와 함께 개정 제어(예: Git)에서 확인할 수 있으므로 어떤 버전의 코드가 어떤 종속성 버전에 따라 달라지는지 항상 알 수 있습니다.
  • 위의 내용을 통해 다른 개발자가 동일한 Linux 배포판을 사용하지 않거나 심지어 다른 운영 체제를 사용하지 않더라도 사용된 종속성이 Mac 및 Windows 또는 사용 중인 모든 장치에서 작동할 수 있는 경우 프로젝트에서 공동 작업할 수 있습니다.
  • 운영 체제 패키지 관리자의 자동 업데이트로 인해 코드가 손상되는 것을 원하지 않습니다. 종속성을 업데이트해야 하지만 코드를 수정하거나 업데이트를 롤백할 준비가 되도록 선택한 시점에 의도적으로 업데이트해야 합니다. (개정 제어 시스템의 코드와 함께 전체 종속성 선언을 추적하면 쉽습니다.)

직접 종속성과 간접 종속성을 분리해야 한다고 생각하는 경우(또는 종속성의 허용 가능한 버전 범위와 실제로 사용된 버전을 구별해야 하는 경우 "버전 고정" 참조) pip-tools 및/또는 Pipelinev를 살펴보세요. 또한 이를 통해 빌드 종속성과 테스트 종속성을 구별할 수 있습니다. (빌드 종속성과 런타임 종속성 사이의 차이점은 아마도 에 코딩될 수 있습니다 setup.py.)

사용하는 애플리케이션

일반 응용 프로그램으로 사용하는 것의 경우방금 일어난 일이야Python으로 작성하려면 운영 체제의 패키지 관리자를 선택하세요. 이를 통해 합리적으로 최신 상태를 유지하고 패키지 관리자가 설치한 다른 항목과 호환되도록 할 수 있습니다. 또한 대부분의 Linux 배포판은 악성 코드를 배포하지 않는다고 주장합니다.

필요한 것이 배포판의 기본 패키지 저장소에 없으면 다른 패키지 저장소(예: deb 기반 배포판의 런치패드)를 확인하거나 pip어쨌든 사용할 수 있습니다. 후자의 경우 --user시스템 전체가 아닌 사용자의 집에 설치하는 방법을 사용하면 Python 설치가 중단될 가능성이 줄어듭니다. (일시적으로 또는 드물게 필요한 경우에는 virtualenv를 사용할 수도 있습니다.)

답변3

패키지 관리자를 사용하는 또 다른 이유는 업데이트가 자동으로 적용된다는 점인데, 이는 보안에 매우 중요합니다. Equifax에서 사용하는 Bean 패키지가 yum-cron-security를 ​​통해 자동으로 업데이트되었다면 해커 공격이 발생하지 않았을 수도 있습니다.

내 개인 개발 상자에서는 Pip을 사용하고 프로덕션에서는 패키지를 사용합니다.

답변4

일반화하다

작업 중인 모듈은 세 가지 범주로 분류됩니다.

  1. 이러한 지원 프로그램은 운영 체제 패키지 시스템의 모든 사용자를 위해 설치됩니다. (여기에는 Python으로 프로그래밍하는 사람들을 위한 도구와 라이브러리도 포함될 수 있습니다. 아래를 참조하십시오.) 이를 위해 가능한 경우 운영 체제 패키지를 사용하고 pip필요할 때 시스템 디렉터리에 설치할 수 있습니다.
  2. 특정 사용자가 설치한 지원 프로그램은 그 사용자 자신만을 위한 것이며 Python을 스크립트 언어로 "일상" 사용하는 특정 측면을 위한 것입니다. 그녀는 이것들을 위해 pip --user아마도피엔브또는파이썬, 유사한 도구 및 전략.
  3. 특정 애플리케이션의 개발 및 사용을 지원합니다. 이를 위해 virtualenv(또는 유사한 도구)를 사용할 수 있습니다 .

여기의 각 레벨은 이전 레벨에서도 지원될 수 있습니다. 예를 들어, (2)의 사용자는 운영 체제 패키지를 통해 설치된 Python 인터프리터에 의존할 수 있습니다.

이에 대해 더 자세히 논의하면 다음과 같습니다.

시스템 프로그램 및 소프트웨어 패키지

"그냥 실행"하려는 Python으로 작성된 프로그램은 간단합니다. 운영 체제 설치 도구를 사용하여 필요한 모든 것을 가져오도록 하면 Python이 아닌 프로그램과 다르지 않습니다. 이는 사용자가 종속성을 이해하고 이상적으로는 그렇지 않은 호스트에서 이를 처리하는 방법을 알고 있는 한 컴퓨터의 사용자가 의존하기 시작할 수 있는 Python 도구/라이브러리를 도입할 수 있습니다. 이러한 종속성을 제공하면 문제가 되지 않습니다.

이 종속성에 대한 일반적이고 간단한 예 는 RH/CentOS 7 및 대부분(전부는 아님) Ubuntu 설치(Python 2에서 실행되는 한)에서 잘 작동하는 일부 개인 스크립트입니다 ~/.local/bin/. #!/usr/bin/env python기본 Debian 설치 또는 Windows에서 실행됩니다. 나는 내 개인 환경이 운영 체제 패키지에 많은 의존성을 갖고 있는 것을 좋아하지 않지만(저는 다양한 운영 체제에서 작업합니다), 그러한 것이 제가 가지고 있지 않은 드문 경우에는 상당히 수용 가능하다고 생각합니다. Python 시스템이고 호스트 시스템에서 Python을 가져올 수 없는 경우 백업 계획은 아래 설명된 대로 사용자 시스템을 사용하는 것입니다.

시스템 Python 인터프리터를 사용하는 사람들은 대개 시스템에 따라 다릅니다 pip3. 여기서는 일반적으로 시스템 종속성에 대해 선을 긋습니다. 그 이후의 모든 작업은 virtualenv제가 직접 처리합니다. (예를 들어, 내표준 활성화 스크립트경로에 있는 모든 것에 의존 pip3하지만 생성 중인 가상 환경을 부트스트랩하기 위해 자체 복사본을 다운로드합니다.pipvirtualenv

즉, 어떤 경우에는 더 많은 개발 환경을 제공하는 것이 전적으로 합리적일 수 있습니다. 시스템 버전의 패키지를 사용하려는 복잡한 패키지(예: DBMS)에 Python 인터페이스를 연결할 수 있으며, 시스템에서 원하는 특정 Python 라이브러리 코드를 선택하도록 하는 것이 가장 좋을 것이라고 생각합니다. 그것과 통신하는 데 사용합니다. 또는 Python과 유사한 기본 개발 환경을 사용하여 다수의 호스트에 배포하고 표준 시스템 패키지를 사용하여 자동화하는 것이 가장 쉬운 방법일 수 있습니다.

사용자 "일일" 프로그램 및 패키지

사용자는 처음에 가상 환경을 만드는 데 도움을 주기를 원하기 때문에 가상 환경에 적합하지 않은 Python 라이브러리나 프로그램을 가지고 있을 수 있습니다(예:가상 환경 래퍼) 또는 Python이 아닌 작업을 수행할 때에도 일반적으로 명령줄에서 사용하는 것입니다. 이러한 도구의 시스템 버전을 설치할 수 있는 능력이 있더라도 자신의 도구를 설치하는 것이 더 편할 수 있습니다(예를 들어 최신 버전의 도구 및 해당 종속성을 사용하기를 원하기 때문).

일반적으로 pip --user사람들은 이를 위해 이를 사용하지만 일부 종속성(예: Python 인터프리터 자체)에는 더 많은 것이 필요합니다.피엔브그리고파이썬개인 인터프리터를 구축하는 데 유용합니다(기본 인터프리터로 설치하든 다른 인터프리터로 설치하든) ~/.local/bin. 물론 개발 라이브러리를 사용할 수 있는 경우 항상 소스에서 "수동으로" 구축할 수 있습니다.

나는 여기에 최소한의 설치를 시도했습니다: virtualenvwrapper(나는 그것을 많이 사용하기 때문에) 그리고 어쩌면 최신 버전의 pip일 수도 있습니다. 많은 호스트에서 사용하기 위해 작성하는 개인 스크립트의 경우 표준 라이브러리나 Python 3 이외의 항목에 의존하지 않으려고 노력합니다. (하지만 점점 더 많은 개인 스크립트를 Python으로 옮기면서 이것을 얼마나 오랫동안 유지할 수 있는지 살펴보겠습니다.)

독립적인 애플리케이션 개발 및 런타임 환경

이것은 일반적인 virtualenv입니다. 개발의 경우 거의 항상 virtualenv를 사용하여 시스템 종속성을 사용하지 않는지 확인하거나 여러 virtualenv를 사용하여 다양한 Python 버전에 대해 테스트하는 경우가 많습니다.

이러한 가상 환경은 사용자 환경을 오염시키지 않으려는 종속성이 많은 애플리케이션에도 적합합니다. 예를 들어 저는 보통 virtualenv를 설정하여 실행합니다.목성노트북 등.

관련 정보