라이브러리가 모든 프로그램과 함께 제공되지 않고 별도로 제공되는 이유는 무엇입니까?

나는 이것이 더 빠른 보안 수정, 더 쉬운 패키징, 더 많은 기능과 같은 일반적인 이유를 알고 있습니다. 그러나 나는 우리의 프로그램에 라이브러리를 번들로 묶을 필요가없는 일부 동료들을 설득하려고 노력하고 있습니다. 이 라이브러리가 없으면 작동하지 않지만 라이브러리는 한동안 안정되어 있으며 가까운 미래에도 계속 유지 될 것입니다. 번들을 풀지 않을 이유가 없습니다.

설득하기 위해 어떤 주장을 사용할 수 있습니까?

내 구체적인 상황은 이것입니다 : 저는 심볼 수학을위한 오픈 소스 Python 라이브러리 인 SymPy 에서 일하고 있습니다. 그것의 핵심 부분은 mpmath 이며, 이는 다중 프로비저닝 부동 소수점 산술을위한 라이브러리입니다. mpP 없이는 SymPy가 작동하지 않으며 대안이 없습니다. 따라서 시작 이후 SymPy와 번들로 제공되었습니다 (새 버전을 가져올 때마다 수정해야 할 비 호환성이 일반적이라고 들었습니다). mpmath 개발자는 SymPy 개발에 참여 했었다는 점도 주목해야합니다. 이제 mpmath 번들링에 대한 문제가 있습니다 . 여기서 읽을 수 있습니다 .

토론을 요약하면 다음과 같습니다.

묶음 해제 :

• 다소 쉬운 파이썬 3 포팅 ​​(사소한 인수 IMHO)

• 배포를위한 더 쉬운 패키징

• 사용자에게 더 빠른 (보안) 기능 업데이트

• "패키징 및 처리 종속성은 어려운 문제이지만 해결되었습니다. 이것은 우리가 스스로해야 할 영역이 아닙니다."

묶음 유지 :

• 설치. Linux에서는 쉽고, Mac에서는 어렵고 Windows에서는 매우 어렵습니다. su 액세스 부족 및 기타 문제.

• SymPy의 필수 부분입니다. 즉, sympy가 없으면 작동하지 않습니다.

• mpmath의 작업을 수행 할 수있는 다른 패키지 가 없습니다.

• "사용자로서 sympy를 다운로드하면 제대로 작동하기를 기대합니다."

그것은 나의 구체적인 상황이지만, 좋은 일반적인 대답을 제공하는 대답을 받아들입니다.

또 다른 대답이지만 가장 중요한 것으로 간주되는 답변 (단지 내 개인적인 의견)이지만 다른 답변도 모두 좋은 답변입니다.

lib를 별도로 패키징하면 응용 프로그램을 업데이트하지 않고도 lib를 업데이트 할 수 있습니다. lib를 업데이트하는 대신 lib에 버그가 있다고 가정하면 전체 응용 프로그램을 업데이트해야합니다. 즉, 응용 프로그램이 lib 때문에 코드가 변경되지 않은 버전 충돌이 필요합니다.

언급 한 장점 (보안, 패키징, 기능) 외에도 몇 가지 더 생각할 수 있습니다.

• 다른 프로그램에 유용한 기능을 찾는 사람은 분리하는 작업을 수행 할 필요가 없습니다. 그것은 그녀가 기능이 프로젝트에 라이브러리 형태로 존재 하는지를 아는 경우에도 처음입니다. 이것은 프로젝트가 모듈식이라면 얼마나 잘 설계되었는지에 달려 있습니다.

• 다른 프로젝트에 유용 할 경우, 일반적으로 디스크 사용량이 줄어 듭니다 (예 : 코드 사본 한 개만).

• 이것은 코드의 품질을 향상 시켜서 (필요한) 리팩토링을 강요합니다. 위의 첫 번째 지점에서와 마찬가지로 이것은 코드의 품질에 따라 다릅니다.

• 라이브러리 사용자 수를 늘리면 (분할 된 경우) 라이브러리를보다 일반적으로 만드는 데 도움이되므로 품질도 향상 될 수 있습니다.

장점은 분명하지만 배포가 용이 한 것은 사용자의 경우 프로그램과 함께 라이브러리를 제공하는 주요 논거 인 것 같습니다.

번들링에 대한 몇 가지 주장이 있습니다.

• Linux에서는 라이브러리가 해당 종속성과 잘 작동하는지 확인하는 것이 배포 관리자의 작업입니다. 대부분의 사용자는 배포판의 패키지 관리자를 사용하여 라이브러리를 다운로드합니다. 트렁크를 사용하는 사람들은 일반적으로 라이브러리 구성에 시간을 소비하지 않아도됩니다.

• Windows 및 Mac OS에서는 pip와 같은 Python 패키지 관리자가 일반적으로 사용됩니다. 라이브러리를 직접 설치하는 것은 번거롭기 때문입니다.

• Google 앱 엔진에 하드 배포에 대한 논쟁이 있었지만 모든 웹 프레임 워크가 실행되는 것은 아닙니다. 많은 사람들은 포팅이 필요하고 라이브러리의 디스크 공간이 제한되어 있으며 결국 웹 응용 프로그램 호스팅입니다! 웹 애플리케이션이 기호 수학을 사용하지는 않습니다.

• 종속성을 사용할 수 없거나 버전이 잘못된 경우 아무도 깨끗한 오류 메시지를 표시하지 않습니다.

• 사람들은 프로그램이 자신보다 더 영리하다고 생각할 때 종종 그것을 싫어합니다. 사용자가 자신의 시스템을 관리하도록합니다.

적절한 방법은 패키지 라이브러리의 존재에 대한 PREINST 테스트를하는 것입니다 설치 윈도우에 번들로 처리하고, 그것이 존재하지의 경우 소프트웨어 설치 패키지에 포함하는 라이브러리 패키지에서 설치하는 것을 제안 할 수 있습니다. Windows 포트가있는 대부분의 GTK 앱은이 라인을 따라 무언가를 수행합니다 . 피진 은 알고 있습니다.

하나의 크기가 모든 것을 충족시킬 필요는 없습니다.

소스 배포의 경우 번들로 묶으면 여러 배포판 (적어도 데비안 및 Fedora 헤리티지)의 패키지 관리자는 번들을 비활성화하거나 제거하기 위해 추가 작업을 수행해야합니다. 이러한 플랫폼에 대한 패키지 정책은 번들링을 금지하거나 적어도 방해하지 않기 때문입니다. 따라서 번들링을하면 거의 이점없이 다운 스트림에 더 많은 작업을 생성 할 수 있습니다. 그 주장에 무게가 있습니까?

이진 분포 (제공 한 경우)는 어느 쪽이든 갈 수 있습니다. 번들링은 다운 스트림에서 사용되지 않기 때문에 아마도 의미가 있습니다.

그러나 Windows 및 Mac 설치 프로그램에 대해 반대 결정을 내릴 수없는 이유는 없습니다.

번들링 대 의존은 패키징 세계에서 오래된 논쟁입니다. 이 문서는 다음 두 가지 생각 학교에 대해 설명합니다. http://www.aosabook.org/en/packaging.html