Neden bir kütüphane klasörü yerine paket yöneticisini tercih edersiniz?

Statik bir kütüphane klasörünün ve paket yöneticisinin artılarını ve eksilerini düşündüğümde kütüphane klasörünün daha iyi bir yaklaşım olduğunu düşünüyorum.

Bir kütüphane klasörü ile görüyorum artıları:

1. Paketleri yönetmek için harici bir araca gerek yok.
2. İnşa etmek için internet bağlantısı gerekmez.
3. Daha hızlı yapı (paket kontrolü yok).
4. Daha basit ortam (daha az bilgi gerekli).

Bir paket yöneticisi ile görüyorum artıları:

1. Karmaşık bağımlılık ağaçlarına yardımcı olur (ve tüm bağımlılıklarla birlikte bir bağımlılık indirerek yönetilebilir).
2. Kullanılabilir yeni bir sürüm olup olmadığını kontrol etmeye yardımcı olur.

Sektörün bugün inşa edilen hemen hemen her şey için paket yöneticisi yolunu izlemeye karar verdiği anlaşılıyor. Peki neyi özlüyorum?

Diğer cevaplarda eksik olan önemli bir nokta:

Bir paket yöneticisi kullanmak, hangi kütüphane sürümlerini kullandığınızı belirten ve yapılandırma bilgilerinin gerçekten doğru olduğundan emin olan bir yapılandırmaya sahip olmak anlamına gelir .

Hangi kitaplıkları kullandığınızı ve hangi sürümü kullandığınızı bilmek, eğer:

• kritik bir hata / güvenlik boşluğu nedeniyle bir kütüphaneyi güncellemeniz gerekir;
• ya da sadece ilan edilen güvenlik boşluğunun sizi etkileyip etkilemediğini kontrol etmeniz gerekir.

Ayrıca, gerçekten güncelleme yaptığınızda, paket yöneticisi (genellikle) geçişli bağımlılıkların gerektiği gibi güncellendiğinden emin olur.

Oysaki bir libklasörde, sadece bir kaç (muhtemelen ikili ve muhtemelen değiştirilmiş) dosyaya sahipsiniz ve nereden geldiklerini ve hangi sürümden olduklarını tahmin etmeniz gerekecek (veya bazı README’ye güvenebilir, bu doğru olabilir veya olmayabilir). ).

Diğer puanlarınızı ele almak için:

Paketleri yönetmek için harici bir araca gerek yok.

Doğru, ancak a) bir yazılım geliştiricisi olarak yine de bir çok araç yüklemeniz gerekir, bu yüzden bir tane daha farketmez, ve b) genellikle herhangi bir alanda yalnızca bir veya birkaç paket yöneticisi vardır (Maven / Gradle for Java, JS / TypeScript, vb. için npm, bu yüzden onlarca kurmanız gerekmiyor.

İnşa etmek için internet bağlantısı gerekmez.

Tanıdığım tüm paket yöneticileri, gerekli bağımlılıkları indirdikten sonra (projenin kendisini indirdikten hemen sonra gerçekleşebilecek olan) çevrimdışı çalışır.

Daha hızlı yapı (paket kontrolü yok).

Muhtemelen doğru, ancak çevrimdışı paket kontrolünün önemli miktarda zaman alacağı düşünülüyor (sadece bazı sürüm numaraları karşılaştırılıyor). Bir çevrimiçi çek biraz zaman alabilir, ancak istenirse (varsayılan olarak bile açıksa - Maven örneğin bırakma sürümleri için güncellemeleri kontrol eder hiç) o kapatılabilir.

Daha basit ortamlar (daha az bilgi gerekli).

Doğru, ancak yukarıda açıklandığı gibi, bir libklasör de bilgi gerektirir. Ayrıca, yukarıda açıklandığı gibi, muhtemelen yalnızca zaten bileceğiniz bir avuç farklı paket yöneticisi ile çalışacaksınız.

Küçük ölçekli geliştirmeden daha büyük çalışmaya geçtiğinizde lib klasörünün artıları hızla kayboluyor.

Örneğin, harici bir araç gerektirmemesinin "faydası", bağımlılıklarınızı manuel olarak yönetmek için gereken iş tarafından sağlanmıştır, bu nedenle araç siz (dünyanın birden fazla anlamında) olacak.

Paket yöneticisi için internet bağlantısına ihtiyacınız yoktur. Yerel depoları kullanabilirsiniz.

Daha hızlı kurulum doğru olabilir, ancak bir paket yöneticisinin kullanılıp kullanılmayacağını belirlemesi gereken bir şey değildir. Sonuçta farkın büyüklüklerinden bahsetmiyoruz ve bu da sizin yapılandırmanıza bağlı. Bir paket yöneticisini kullanarak kolayca yavaş bir yapı oluşturabilirsiniz, ancak bu temelde sabotajdır.

Daha basit ortamlar (daha az bilgi gerekli)? Yine küçük ölçekli kalkınmada kesinlikle bir olasılık. Projeyi, kullanılan kütüphanelerin her birine kadar tamamen kafanızda tutabilirsiniz. Basit bir makefile / other build script ekleyin ve kendinize tam bir paket getirin.

Ama değil yapmak sadece basit ortamlarda çalışır, ortamlar daha basit. Daha büyük ölçekli geliştirmede, özel çözümler yerine standart takımlar kullandığınız için mutlu olacaksınız. Ne de olsa, sadece bir kez öğrenmek zorundasınız (ve du jour paket yöneticisi yeni bir şey ile değiştirilirse, bunu da öğrenmek zorundasınız).

Paket yöneticilerinin avantajlarının çoğunu kaçırıyorsunuz .

1. Paket yöneticileri büyük (birkaç megabayt veya daha büyük) ikili dosyaları kaynak kontrolünde kontrol etmekten kaçınmanıza izin verir. Bunu yapmak, pek çok kaynak kontrol aracına bir anatemadır; en yaygın olanı bunlardan biridir. Birkaç ay önce Bit Bucket'ın boyut sınırlarını dolduran bir depo vardı, çünkü geliştiriciler CocoaPod'ları kontrol ediyordu. SVN'den göç ettiğimizde başka bir proje zaten mevcuttu çünkü tüm lib ikili dosyalarımızı kontrol ediyorduk (ve NuGet'i kullanmıyorduk). Paket yöneticileri her geliştirici için paketleri anında indirebileceğinden, bu ikili dosyaları kontrol etme gereksinimini ortadan kaldırır.
2. Uyumsuz dosyaların / kitaplıkların karıştırılmasını önler. Biri yükseltme sırasında birileri düzgün şekilde temizlemezse, klasörler kütüphanenin dosyalarının karışık sürümlerini içerebilir. Klasördeki ikililerin yarısının yükseltildiği, çok garip hatalara neden olan bir durum gördüm . (Çarpışmadı bile!) Sorunu çözmemiz bizi aylarca (insan saatlerini değil, tam zamanı) aldı. Paket yöneticisinin tüm klasörü kontrol etmesine izin vererek karışık sürümleri alamazsınız; tutarlılığı sağlarsınız. Ayrıca , her şeyi otomatik olarak güncelleyerek, gerektiğinde farklı sürümler yükleyerek veya kütüphanelerin uyumsuz sürümlerini kullanmaya çalışırken yalnızca uyarılar veya hatalar fırlatarak uyumsuz bağımlılıklar kullanmayı daha da zorlaştırıyorlar .
3. Kütüphaneleri yönetmek için ortak bir kongre kurarlar . Projenize, ekibinize, şirketinize vb. Yeni geliştiriciler girdiğinde, paket yöneticisinin sözleşmelerini bilmeleri muhtemeldir. Bu, kütüphanelerinizin kod tabanınızda nasıl yönetildiğinin ayrıntılarını bulmak için zaman harcamak zorunda olmadıkları anlamına gelir.
4. Size kendi bağımlılıklarınızı ve havuzunuza ait olmayan dosyaları sürümleme ve dağıtma konusunda standart bir yol sunarlar. Hatta uygulamamın gerektirdiği bazı büyük statik veri dosyaları için kişisel olarak bunlardan faydalandım, bu yüzden ikili kod dışındaki şeyleri sürümlendirmek için iyi çalışıyor.
5. Bazı paket yöneticileri yükleme sırasında ek özellikler sağlar. NuGet, csproj dosyanıza bağımlılıklar ve içerik dosyaları ekler ve hatta config dosyasına yapılandırma öğeleri de ekleyebilir.
6. Paket listesi dosyaları, kütüphanelerinizin sürümlerini tek ve merkezi bir yerde belgeler. Bir DLL dosyasını sağ tıklatıp kütüphanenin hangi sürümünü kullandığımı bulmak için sürüm numarasına bakmam gerekmez. Python'da, kütüphane yazarı py dosyalarına sürüm numarasını bile eklememiş olabilir, bu yüzden kütüphane sürümünü onlardan bile söyleyemeyeceğim.
7. Makinenin geniş bağımlılık kurulumunu engeller. Paket yöneticileri, bağımlılıkları genel bir yükleyici olmadan kurmanın geleneksel bir yolunu sunar . Seçenekleriniz lib klasörü ve global kurulum olduğunda, birçok kütüphane geliştiricisi kütüphanelerini birincil olarak kendiniz kurmanız gereken indirilebilir ikili dosyalar yerine genel kurulumlar olarak sunmayı seçecektir. (MS geçmişi bunu göstermektedir. Linux'taki birçok kütüphanede de geçerlidir.) Bu, aslında birden fazla projeyi yönetmeyi zorlaştırmaktadır, çünkü çelişkili sürümleri olan projeleriniz olabilir ve bazı geliştiriciler kendi kütüphanelerine sahip olmak için görünüşte daha basit olan global kurulumu seçeceklerdir. dir.
8. Hosting ve dağıtım merkezileştirme eğilimindedirler. Artık o rasgele kütüphanenin web sitesine bağlı kalmak zorunda değilsiniz. İşleri biterse, başarılı bir paket yöneticisinin sitesi hala tüm sürümlerini yükledi. Geliştiriciler ayrıca sadece yeni kütüphaneleri indirmek için pek çok web sitesi aramak zorunda kalmazlar; Onlar ilk bakmak ve hatta farklı seçeneklere göz atmak için gidilecek yer var. Ayrıca, standart bir şekilde organize edilmiş paketleri yansıtmak, geçici web sitelerinden her şeyin kopyasını manuel olarak almaktan daha kolaydır.

Ayrıca, "faydalarınızın" değerini de abartıyorsunuz.

1. Paketleri yönetmek için harici bir araca gerek yok.

   Neye "Dış"? NuGet'in depolanabileceğini kontrol ediyorum. Bu küçük, çünkü başka hiçbir ikiliyi kontrol etmem gerekmediği için, kontrol ettiğimi düşündüğüm tek ikili.

   pip, varsayılan olarak Python ile paketlendiğinden ve uyumsuz ve geriye dönük uyumsuz değişikliklerin son derece nadir olduğu için bu cephede sorun yaratmıyor. Yine de projenize harici olarak Python'u kurmadan Python kodu geliştirmeyeceksiniz.

   Yaygın olarak benimsendiklerinde, paket yöneticileri çok kararlı olma eğilimindedir. Sen uzakta olmadan alamayan bazı çok proje için global olarak yüklenmiş kalıp tür ve tek bir paket yöneticisi oldukça hafif gerekliliktir. Genellikle, dil çalışma zamanının yüklenmesinden çok hantal değildir.

2. İnşa etmek için internet bağlantısı gerekmez.

   Ağ bağlantısı olmadan veritabanıma bağlanamıyorum. Veritabanı Amazon barındırılıyorsa, yine de tam bir internet bağlantısına ihtiyacım var. Kaynak kontrolü ile değişiklikleri zorlamak ve çekmek için bir İnternet bağlantısına ihtiyacım var; Bir derleme sunucusu da bir tür ağ bağlantısı olmadan derlenecek kodu kontrol edemez. Biri olmadan e-posta gönderemez veya alamazsınız . Bunları lib klasörünüze koymak için kütüphaneleri indiremezsiniz! Kalıcı bir internet bağlantısı olmadan gelişen neredeyse hiç duyulmamış. Gerekli olduğu bazı nadir durumlarda, paketleri paket yöneticisinin tüketebileceği bir yere indirerek başa çıkabilirsiniz. (NuGet ve pip'in basit bir klasör veya ağ sürücüsünden çekmekten çok mutlu olduğunu biliyorum; başkalarının da yapabileceğinden şüpheleniyorum.)

3. Daha hızlı yapı (paket kontrolü yok).

   Otomatik yapım sırasında 30 saniye ve yerel geliştirmeler sırasında 5 saniye yukarıda belirtilen faydalar için iyi bir takas. Bunlar , faydaların çözdüğü sorunlara kıyasla genellikle göz önünde bulundurmaya bile değmeyen önemsiz zaman çerçeveleridir.

4. Daha basit ortamlar (daha az bilgi gerekli).

   Kütüphane yönetimi için hiçbir şeye karşı paket yönetimi için bir araç , zaten adil bir karşılaştırma değildir. Bu araç olmadan, projenin kullandığı özel süreci öğrenmek zorundasınız.kütüphanelerini yönetmek için. Bu, mevcut bilgilerinizin yaklaştığınız yeni projeler için geçerli olup olmadığından asla emin olamayacağınız anlamına gelir. Birinin ortaya çıktığı hodgepodge yaklaşımı ile uğraşmak zorundasın, ya da kendi kararını ver. Bu, tüm kütüphaneleri içeren bir dizin olabilir veya daha tuhaf bir şey olabilir. Belki kitaplıkları kontrol etmekten kaçınmak için, birileri hepsini bir ağ sürücüsüne yerleştirmiştir ve tek sürüm göstergesi klasör adıdır. Bu ya da global bir kurulum gerçekten daha iyi nasıl? Buna karşılık, bir paket yöneticisi size karşılaştığınız çoğu projeye uygulanacak temiz bir kongre sunar.

Ortak tema, yalnızca projeler içinde değil aynı zamanda bunlar arasında bile tutarlılık, dokümantasyon ve özellikler sağlamalarıdır. Bu herkesin hayatını kolaylaştırır.

Son zamanlarda ürünümüzü el ile indirilen kitaplıkları kullanmaktan Nuget ile otomatik paket yönetimine dönüştürdüğümde, bir paket yöneticisi kullanmanın büyük faydaları olduğunu söyleyebilirim.

Ürünümüz, bugünün standartlarına göre nispeten küçük olan 27 C # projesinde uygulanmaktadır. Üçüncü taraf bağımlılıklarımızdan bazıları düzinelerce meclise sahiptir.

Nuget'ten önce, tüm bağımlılıklarımızı en son sürüme güncellemek isteseydim, şunu yapmak zorundaydım:

1. Güncellenen kütüphanelerin tümünü nereden bulabilirim?
2. Onları indirin ve unzip / install
3. Kaynak kontrolüne yeni sürümler ekleyin
4. Projelerimizdeki tüm referansları manuel olarak inceleyin ve yeni montajlara işaret etmek için güncelleyin

27 proje ve düzinelerce bağımlılık meclisi ile bu süreç çok yanlıştı ve saatler sürebilirdi.

Şimdi Nuget kullanarak güncellendiğimize göre, hepsi benim için tek bir komutla bitti.

Paketleri yönetmek için harici bir araca gerek yok

Bu bir anlam ifade etmiyor mu? Bir paket yöneticisi kullanırsam, bir lib klasörüne sahip olmam gerekmez. Ayrıca paketleri kendim yönetmek zorunda değilim.

İnşa etmek için internet bağlantısı gerekmez

Geliştirme sırasında bugün internet bağlantısına sahip olmamanın yanı sıra, nadiren de olsa (belki transit olma dışında), düzgün bir paket yöneticisi uygulamanızı oluşturmak için en son sürüme sahip olmanız gerekmemelidir. Şikayet edebilir, ancak daha önce kurulu olan sürümle derhal kurmamaya gerek yok

Daha hızlı yapı (paket kontrolü yok)

Bu oldukça marjinal bir sürat patlaması, ancak bunun için muhtemelen bir noktaya değinebilirsiniz.

Daha basit ortamlar (daha az bilgi gerekli)

Paket yöneticilerinin çoğu, bugünlerde o kadar basittir ki, bunları yaparak etraflarında dolanmaya çalışmakta fayda var. İstersen görsel müşteriler bile var. Onlar aslında olan sürtüğün çoğunu gizliyorlar.

Paket yöneticileri bu paketleri farklı projeler arasında paylaşmanıza da izin verir. Projelerimden 5'i aynı Boost sürümünü kullanıyorsa, bunu her proje için çoğaltmanıza gerek yoktur. Bu, özellikle bahsettiğiniz karmaşık bağımlılık ağaçları için geçerlidir.

Bir lib klasörü ile sadece o proje için paketleri yönetirsiniz, bir paket yöneticisi ise bunu tüm geliştirme ortamınız için tek bir araçla yapmanıza izin verir.

Yalnızca kütüphaneleri kullanmak (lib dizini) ile bunları kullanmak, meta-bilgiyi (paket yöneticisi) korumak arasındaki farktır . Böyle bir meta-bilgi versiyon numaraları, kütüphaneler arasındaki (geçişli) bağımlılıklar ile ilgilidir.

DLL cehennemi, kütüphane uyumluluğu, java modül sistemi, OSGi ve benzeri tartışmaları, en azından bir miktar bağımlılık yönetimine sahip olmaya ikna edici olmalıdır.

• Kütüphane sürümü ve bağımlılık sorunları zaman kaybı olabilir.

Ayrıca paylaşılan (yerel) bir deponun yararı vardır, bu nedenle birçok projenin ithal edilen kütüphanelerin kopyalarını saklaması gerekmez. Birinin 20 alt modülü olan bir projesi varsa, bu modüllerin bazıları 40 garip bağımlılığa sahiptir.

• Daha yapısı
• Kütüphanelerin daha fazla kırpılması
• Kütüphaneler hakkında geçici insan kararları yok

Bir lib klasörünün gerekli olabileceği bazı durumlar vardır, örneğin eski kütüphaneler (bunun bir versiyonu artık korunmaz / mevcut değildir), bir kütüphanenin yerel olarak değiştirilmiş bir versiyonu ...

Ancak her şey için, paket yöneticisinin rolünü üstlenen geliştirici gibidir:

• Geliştiricinin kütüphaneleri indirmesi gerekir (internet gerekli)
• Geliştiricinin daha yeni sürümleri manuel olarak kontrol etmesi gerekir
• ...

Ve IMHO, bu daha az bilgi gerektiriyor, çünkü harici aracın kullanımı hakkında bilgi edinmek zorundasınız, fakat kütüphaneler hakkında daha az bilgi (bağımlılıklar gibi).

Başka soruların kapsamadığı bir başka sorun daha var: paylaşım komisyonları.

Diyelim ki aynı kütüphaneyi inşa eden iki paketiniz var . En iyi durumda, herhangi bir çakışma olmayacak, ancak aynı HDD / SSD alanı iki kez kullanıldı. En kötüsü, sürümler gibi varios çatışmaları olacak.

Paket yöneticisini kullanırsanız, kitaplığı yalnızca bir kez kuracak (sürüm başına) ve zaten ona yol sağlayacaktır.

Not: Tabii ki, bu profesyonelliği elde etmek için dinamik bağlantıya (veya kendi dilinizde benzer bir işlev) ihtiyacınız var.

Paylaşılan kütüphanelerin 90'lı yılların Unix ve Windows sistemlerinde bir ilerleme unsuru olarak görülmesinin temel sebeplerinden biri, aynı kütüphaneleri kullanan birden fazla program yüklendiğinde RAM kullanımını nasıl azaltabilecekleriydi. Kod alanı yalnızca tam kitaplığa ve bu kitaplığın sürümüne bir ONCE tahsis edilmesi gerekir , kalan tek örnek başına bellek kullanımı statik değişkenler içindir.

Birçok işletim sistemi, ortak kütüphaneleri, unix mmap () api gibi mekanizmalara bağlı bir şekilde uygular - bu da bir kütüphanenin sadece aynı sürümde olması gerekmeyeceği, aynı zamanda aynı DOSYA olması gerektiği anlamına gelir. Bu, kendi kütüphanelerini içeren bir programdan tam anlamıyla faydalanmak imkansızdır.

Hafızanın çok daha ucuz olduğu ve kütüphane sürümlerinin 90'lı yıllara göre daha çeşitli olması gerektiğine göre, bu argüman bugün çok fazla ağırlık taşımamaktadır.