라이브러리 폴더보다 패키지 관리자를 선호하는 이유는 무엇입니까?

정적 라이브러리 폴더와 패키지 관리자의 장단점을 생각할 때 라이브러리 폴더가 더 나은 방법이라고 생각합니다.

라이브러리 폴더로 볼 수있는 장점 :

1. 패키지를 관리하기 위해 외부 도구가 필요하지 않습니다.
2. 인터넷 연결이 필요하지 않습니다.
3. 빠른 빌드 (패키지 확인 안 함)
4. 더 간단한 환경 (지식이 필요하지 않음).

패키지 관리자와 함께하는 장점 :

1. 복잡한 종속성 트리를 지원하고 모든 종속성과 함께 종속성을 다운로드하여 관리 할 수 ​​있습니다.
2. 사용 가능한 새 버전이 있는지 확인하는 데 도움이됩니다.

업계는 오늘날 구축 된 거의 모든 것에 대해 패키지 관리자 경로를 따르기로 결정한 것 같습니다. 그래서, 내가 무엇을 놓치고 있습니까?

다른 답변에서 누락 된 중요한 점 :

패키지 관리자를 사용한다는 것은 사용중인 라이브러리 버전 을 나타내는 구성이 있으며 구성 정보가 실제로 올바른지 확인하는 것입니다.

다음과 같은 경우 사용하는 라이브러리와 버전을 아는 것이 매우 중요합니다.

• 중요한 버그 / 보안 결함으로 인해 라이브러리를 업데이트해야합니다.
• 또는 공지 된 보안 허점이 귀하에게 영향을 미치는지 확인해야합니다.

또한 실제로 업데이트 할 때 패키지 관리자는 일반적으로 전이 종속성을 필요에 따라 업데이트합니다.

A를 반면 lib폴더, 당신은 (아마도 이진, 그리고 아마도 수정) 파일의 무리가 있고, 당신은 그들이 어디에서 왔는지 추측해야하고 어떤 버전 그들이 (또는 README, 또는 정확하지 않을 수 있습니다 믿을거야 ).

다른 요점을 해결하려면 :

패키지를 관리하기 위해 외부 도구가 필요하지 않습니다.

그러나 a) 소프트웨어 개발자는 많은 도구를 설치해야하므로 대개 더 중요하지 않으며 b) 일반적으로 특정 필드 (Maven / Gradle for Java, JS / TypeScript 등의 경우 npm) 수십 개를 설치 해야하는 것은 아닙니다.

인터넷 연결이 필요하지 않습니다.

내가 아는 모든 패키지 관리자는 필요한 종속성을 다운로드하면 오프라인으로 작업합니다 (프로젝트 자체를 다운로드 한 직후에 발생할 수 있음).

빠른 빌드 (패키지 확인 안 함)

아마도 사실이지만 오프라인 패키지 확인에 많은 시간이 걸리지 않을 것 같습니다 (일부 버전 번호를 비교하는 것입니다). 온라인 검사는 시간이 걸릴 수 있지만, 원하는 경우 (기본값도에있는 경우 - 메이븐 예를 들어 릴리스 버전에 대한 업데이트를 확인하지 않음) 그 해제 할 수 있습니다.

더 간단한 환경 (지식이 필요하지 않음).

사실이지만 위에서 설명한 것처럼 lib폴더에도 지식이 필요합니다. 또한 위에서 설명한 바와 같이, 이미 알고있는 소수의 다른 패키지 관리자 만 사용할 수 있습니다.

소규모 개발에서 더 큰 작업으로 이동하면 lib 폴더의 장점이 빠르게 사라집니다.

예를 들어, 외부 도구를 필요로하지 않는 "혜택"은 종속성을 수동으로 관리하는 데 필요한 작업보다 우선합니다. 따라서 도구는 여러분이 될 것입니다 (하나 이상의 의미에서).

패키지 관리자를위한 인터넷 연결이 필요하지 않습니다. 로컬 리포지토리를 사용할 수 있습니다.

더 빠른 빌드는 사실이지만 패키지 관리자 사용 여부를 결정하는 것은 아닙니다. 우리는 결국 차이의 크기에 대해 이야기하고 있지 않으며, 이는 구성에 따라 다릅니다. 패키지 관리자를 사용하여 느리게 빌드 할 수 있지만 기본적으로 파괴적입니다.

더 단순한 환경 (지식이 필요하지 않음)? 다시 한번, 소규모 개발에서는 확실히 가능성이 있습니다. 사용중인 몇 개의 라이브러리 각각에 이르기까지 프로젝트를 머리 속에 완전히 담을 수 있습니다. 간단한 makefile / 기타 빌드 스크립트를 추가하면 완전한 패키지가 생깁니다.

그러나 환경을 단순 하게 만들지 않고 단순한 환경에서만 작동합니다. 대규모 개발에서는 사용자 지정 솔루션 대신 표준 툴링을 사용하게되어 기쁩니다. 결국, 당신은 그것을 한 번만 배워야합니다 (패키지 관리자 du jour가 새로운 멋진 것으로 대체되면 그것을 배워야합니다).

패키지 관리자의 많은 장점 이 빠져 있습니다.

1. 패키지 관리자를 사용하면 큰 (수 메가 바이트 이상) 바이너리를 소스 제어에 체크인하지 않아도됩니다. 그렇게하는 것은 많은 소스 제어 도구에 대한 혐오입니다. 개발자가 CocoaPods를 체크인했기 때문에 몇 개월 전에 저장소가 Bit Bucket의 크기 제한에 도달했습니다. SVN에서 마이그레이션 할 때 다른 프로젝트가 이미 반쯤있었습니다. 모든 라이브러리 바이너리를 체크인하고 있었고 NuGet을 사용하지 않았기 때문입니다. 패키지 관리자는 각 개발자를 위해 즉시 패키지를 다운로드하므로이 바이너리를 체크인 할 필요가 없습니다.
2. 호환되지 않는 파일 / 라이브러리가 혼합되는 것을 방지합니다. 업그레이드하는 동안 누군가 폴더를 올바르게 정리하지 않으면 폴더에 라이브러리 파일의 혼합 버전이 포함될 수 있습니다. 폴더의 바이너리 중 절반이 업그레이드되어 매우 이상한 버그가 발생하는 경우를 보았습니다 . (충돌조차도 없었습니다!) 문제를 파악하는 데 문자 그대로 몇 달 (인적 시간이 아니라 전체 시간)이 걸렸습니다. 패키지 관리자가 전체 폴더를 제어하게함으로써 혼합 버전을 얻을 수 없습니다. 일관성을 보장합니다. 또한 모든 것을 자동으로 업데이트하거나 필요한 곳에 다른 버전을 설치하거나 호환되지 않는 버전의 라이브러리를 사용하려고 할 때 경고 나 오류를 발생시켜 호환되지 않는 종속성 을 사용하기가 훨씬 어렵습니다 .
3. 라이브러리 관리를위한 공유 규칙 을 설정합니다 . 새로운 개발자가 프로젝트, 팀, 회사 등에 참여하면 패키지 관리자의 규칙을 알고있을 것입니다. 즉, 코드 기반에서 라이브러리를 관리하는 방법에 대한 세부 정보를 파악하는 데 시간을 낭비하지 않아도됩니다.
4. 리포지토리에 속하지 않는 자신의 종속성과 파일을 버전 관리하고 배포하는 표준 방법을 제공합니다. 내 응용 프로그램에 필요한 일부 큰 정적 데이터 파일에 개인적으로 활용 했으므로 이진 코드 이외의 버전을 지정하는 데 효과적입니다.
5. 일부 패키지 관리자는 설치 중에 추가 기능을 제공합니다. NuGet은 csproj 파일에 종속성 및 컨텐츠 파일을 추가하고 구성 파일에 구성 요소를 추가 할 수도 있습니다.
6. 패키지 목록 파일은 중앙 집중화 된 단일 위치에 라이브러리 버전을 문서화합니다. DLL을 마우스 오른쪽 버튼으로 클릭하고 사용중인 라이브러리의 버전을 파악하기 위해 버전 번호를 볼 필요가 없습니다. 파이썬에서 라이브러리 작성자는 py 파일에 버전 번호를 포함하지 않았을 수도 있으므로 라이브러리 버전을 알려줄 수도 없습니다.
7. 시스템 전체의 종속성 설치를 권장하지 않습니다. 패키지 관리자 는 전역 설치 프로그램없이 종속성을 설치하는 일반적인 방법을 제공합니다 . 옵션이 lib 폴더 및 전역 설치 인 경우 많은 라이브러리 개발자가 직접 설정해야하는 다운로드 가능한 바이너리가 아닌 기본 설치로 라이브러리를 기본 설치하도록 선택합니다. (MS 역사는 이것을 보여줍니다. Linux의 많은 라이브러리의 경우도 마찬가지입니다.) 이것은 충돌하는 버전의 프로젝트가있을 수 있으며 일부 개발자는 자신의 lib를 갖는 것보다 훨씬 간단한 글로벌 설치를 확실히 선택할 것이기 때문에 실제로 여러 프로젝트를 관리하기가 더 어려워집니다 dir.
8. 그들은 호스팅 및 배포를 중앙 집중화하는 경향이 있습니다. 더 이상 해당 랜덤 라이브러리의 웹 사이트에 의존 할 필요가 없습니다. 사업을 중단하더라도 성공적인 패키지 관리자 사이트에는 여전히 모든 버전이 업로드됩니다. 개발자는 새로운 라이브러리를 다운로드하기 위해 많은 웹 사이트를 찾아 다닐 필요가 없습니다. 그들은 먼저보고 다른 옵션을 찾아 갈 수있는 곳이 있습니다. 애드혹 웹 사이트의 모든 사본을 수동으로 호스팅하는 것보다 표준 방식으로 구성된 패키지를 미러링하는 것이 더 쉽습니다.

또한 "혜택"의 가치를 과대 평가하고 있습니다.

1. 패키지를 관리하기 위해 외부 도구가 필요하지 않습니다.

   무엇에 "외부"? NuGet 실행 파일을 내 저장소로 체크인합니다. 크기가 작고 다른 바이너리를 체크인 할 필요가 없기 때문에 체크인하는 것이 괜찮은 바이너리입니다.

   pip는 현재 기본적으로 Python과 번들로 제공되며 호환되지 않는 변경 사항을 깨고 뒤로하는 것이 매우 드물기 때문에이 전선에서 문제가되지 않습니다. 어쨌든 프로젝트 외부에 Python을 설치하지 않고는 Python 코드를 개발하지 않을 것입니다.

   그들이 널리 보급 될 때까지, 패키지 관리자는 매우 안정적인 경향이 있습니다. 당신은 멀리없이 얻을 수없는 몇 가지 대부분의 프로젝트에 대한 전 세계적으로 설치 공구의 종류와 하나의 패키지 관리자는 꽤 가벼운 무게의 요구 사항입니다. 일반적으로 언어 런타임을 설치하는 것보다 훨씬 번거롭지 않습니다.

2. 인터넷 연결이 필요하지 않습니다.

   네트워크 연결이 없으면 데이터베이스에 연결할 수 없습니다. 데이터베이스가 아마존에서 호스팅된다면 어쨌든 완전한 인터넷 연결이 필요합니다. 소스 제어를 통해 변경 사항을 푸시 및 풀하려면 인터넷 연결이 필요합니다. 빌드 서버는 네트워크 연결이 없으면 빌드 할 코드를 체크 아웃 할 수 없습니다. 이메일이 없으면 이메일을 보내거나받을 수 없습니다 . 라이브러리가 없으면 라이브러리를 다운로드하여 lib 폴더에 넣을 수 없습니다! 인터넷 연결없이 영구적으로 개발하는 것은 거의 들어 본 적이 없습니다. 필요한 경우가 드물지만 패키지 관리자가 사용할 수있는 위치로 패키지를 다운로드하여이 문제를 해결할 수 있습니다. (나는 NuGet과 pip가 간단한 폴더 또는 네트워크 드라이브에서 가져 와서 매우 기뻐한다는 것을 알고 있습니다. 다른 사람들도 가능하다고 생각합니다.)

3. 빠른 빌드 (패키지 확인 안 함)

   자동화 된 빌드 동안 30 초, 로컬 개발 빌드 동안 5 초는 위에서 설명한 이점과의 균형이 맞습니다. 이는 혜택이 해결하는 문제와 비교할 때 일반적으로 고려할 가치가없는 사소한 시간입니다.

4. 더 간단한 환경 (지식이 필요하지 않음).

   에 대한 패키지 관리를위한 하나의 도구 아무것도 라이브러리 관리를위한 어쨌든, 정말 공정한 비교가 아닙니다. 도구가 없으면 프로젝트에서 사용중인 사용자 정의 프로세스 를 학습해야합니다.라이브러리를 관리합니다. 즉, 기존 지식이 접근하는 새 프로젝트에 적용되는지 확실하지 않습니다. 누군가가 생각 해낸 호드 포지 접근 방식을 다루거나 자신 만의 방식으로 구성해야합니다. 모든 라이브러리를 포함하는 디렉토리이거나 훨씬 이상 할 수 있습니다. 라이브러리 체크인을 피하기 위해 누군가가 네트워크 드라이브에 라이브러리를 배치하고 유일한 버전 표시기는 폴더 이름입니다. 그 또는 전체 설치가 실제로 어떻게 더 좋습니까? 이에 비해 패키지 관리자는 발생하는 대부분의 프로젝트에 적용 할 깔끔한 규칙을 제공합니다.

공통 주제는 프로젝트 내 에서뿐만 아니라 전체에서 일관성, 문서 및 기능을 제공한다는 것입니다. 이것은 모든 사람의 삶을 단순화시킵니다.

Nuget에서 수동으로 다운로드 한 라이브러리 사용에서 자동 패키지 관리로 제품을 최근에 변환 한 결과 패키지 관리자를 사용하면 큰 이점이 있다고 말할 수 있습니다.

우리의 제품은 27 개의 C # 프로젝트에 걸쳐 구현되어 있으며 오늘날의 표준으로는 상대적으로 작습니다. 타사의 일부 종속성에는 수십 개의 어셈블리가 있습니다.

Nuget 이전에 모든 종속성을 최신 버전으로 업데이트하려면 다음을 수행해야합니다.

1. 업데이트 된 라이브러리를 모두 얻을 수있는 곳을 추적하십시오.
2. 다운로드 및 압축 풀기 / 설치
3. 소스 컨트롤에 새 버전 추가
4. 프로젝트의 모든 참조를 수동으로 살펴보고 새 어셈블리를 가리 키도록 업데이트

27 개의 프로젝트와 수십 개의 종속성 어셈블리가있는이 프로세스는 오류가 발생하기 쉬우 며 몇 시간이 걸릴 수 있습니다.

이제 Nuget 사용으로 업데이트되었으므로 단일 명령으로 모두 완료되었습니다.

패키지 관리를위한 외부 도구 불필요

그것은 일종의 논 포인트입니까? 패키지 관리자를 사용하는 경우 lib 폴더가 필요하지 않습니다. 또한 패키지를 직접 관리 할 필요도 없습니다.

인터넷 연결이 필요하지 않습니다

개발 중에는 인터넷에 연결되어 있지 않은 것을 제외하고는 개발 과정이 다소 드물지만 (운송중인 경우 제외) 괜찮은 패키지 관리자는 응용 프로그램을 빌드하기 위해 최신 버전이 필요하지 않습니다. 불평 할 수는 있지만 이미 설치된 버전으로 빌드하지 않아도됩니다.

빠른 빌드 (패키지 확인 안 함)

그것은 꽤 작은 스피드 부스트이지만, 당신은 그것을 지적 할 수 있습니다.

더 간단한 환경 (지식이 필요하지 않음)

요즘 대부분의 패키지 관리자는 매우 단순하므로 이러한 작업을 수행하여 해결할 수는 없습니다. 원한다면 비주얼 클라이언트도 있습니다. 그들은 실제로 진행되고있는 많은 로프트를 숨 깁니다.

패키지 관리자를 사용하면 다른 프로젝트간에 이러한 패키지를 공유 할 수도 있습니다. 내 프로젝트 중 5 개가 동일한 버전의 Boost를 사용하는 경우 각 프로젝트마다이를 복제 할 필요가 없습니다. 이것은 복잡한 종속성 트리에 대해 특히 그렇습니다.

lib 폴더를 사용하면 해당 프로젝트에 대해서만 패키지를 관리하는 반면 패키지 관리자를 사용하면 단일 도구로 전체 개발 환경에서이 작업을 수행 할 수 있습니다.

그것은 단지 사이의 차이 사용하여 라이브러리 (lib 디렉토리) , 및 유지를 사용하여 메타 정보 (패키지 관리자) . 이러한 메타 정보는 버전 번호, (전이) 라이브러리 간의 의존성에 관한 것입니다.

DLL 지옥, 라이브러리 호환성, 자바 모듈 시스템, OSGi 등에 대한 논의는 최소한 어떤 형태의 의존성 관리를 가질만한 가치가 있다고 확신해야합니다.

• 라이브러리 버전 및 종속성 문제는 시간이 많이 걸릴 수 있습니다.

또한 공유 (로컬) 리포지토리의 이점이 있으므로 여러 프로젝트에서 가져온 라이브러리의 복사본을 유지 관리 할 필요가 없습니다. 하나의 하위 모듈이 20 개인 프로젝트가있는 경우 해당 모듈 중 일부는 40 개의 이상한 종속성을 갖습니다.

• 더 구조
• 라이브러리 다듬기
• 도서관에 대한 임시 인간 결정이 없음

예를 들어 쓸모없는 라이브러리 (더 이상 유지 / 사용할 수없는 버전), 로컬로 수정 된 라이브러리 버전 등을 처리 할 때 lib 폴더가 필요할 수 있습니다.

그러나 다른 모든 경우에는 패키지 관리자의 역할을 가정하는 개발자와 같습니다.

• 개발자는 라이브러리를 다운로드해야합니다 (인터넷 필요)
• 개발자는 수동으로 최신 릴리스를 확인해야합니다
• ...

그리고 IMHO는 외부 도구의 사용법에 대해 알아야하지만 라이브러리 (예 : 종속성)에 대해서는 알아야하기 때문에 지식이 덜 필요합니다.

다른 질문으로는 다루지 않는 또 다른 문제가 있습니다.

동일한 라이브러리를 만드는 두 개의 패키지가 있다고 가정 해 봅시다 . 가장 좋은 경우에는 충돌이 없지만 동일한 HDD / SSD 공간이 두 번 사용 된 것입니다. 최악의 경우 버전과 같은 모호한 충돌이 발생합니다.

패키지 관리자를 사용하는 경우 라이브러리는 한 번만 (버전 당) 라이브러리를 설치하고 이미 경로를 제공합니다.

추신 : 물론이 프로를 이용하려면 동적 연결 (또는 귀하의 언어로 유사한 기능)이 필요합니다.

공유 라이브러리가 90 년대 유닉스와 Windows 시스템에서 진보 된 항목으로 간주 된 한 가지 주요 이유는 동일한 라이브러리 세트를 사용하는 여러 프로그램을로드 할 때 RAM 사용량을 줄이는 방법이었습니다. 코드 공간은 정확한 라이브러리 및 해당 라이브러리의 버전 마다 한 번만 할당 하면되며 나머지 인스턴스 별 메모리 사용량은 정적 변수입니다.

많은 운영 체제는 unix mmap () api와 같은 메커니즘에 의존하는 방식으로 공유 라이브러리를 구현합니다. 이는 라이브러리가 정확히 동일한 버전 일뿐만 아니라 실제로는 동일한 FILE 일 필요가 있음을 의미합니다. 자체 라이브러리 세트를 제공하는 프로그램을 최대한 활용하는 것은 불가능합니다.

메모리가 훨씬 저렴하고 90 년대보다 라이브러리 버전이 더 다양해야한다는 점을 감안할 때 오늘날이 주장은 그다지 중요하지 않습니다.