Kütüphaneler neden her programla birlikte değil ayrı olarak gönderilir?

Bunun neden genel olarak iyi olduğunu biliyorum: daha hızlı güvenlik düzeltmeleri, daha kolay paketleme, daha fazla özellik. Ancak, bazı çalışma arkadaşlarını programımızla birlikte bir kütüphane oluşturmamız gerekmediği konusunda ikna etmeye çalışıyorum. Bu kütüphane olmadan çalışmayacak, ancak kütüphane bir süredir istikrarlı ve öngörülebilir gelecek için öyle kalacak. Ayrıştırmak için bir neden görmüyorum.

Onları ikna etmek için hangi argümanları kullanabilirim?

Benim özel durumum şudur: Sembolik matematik için açık kaynaklı bir Python kütüphanesi olan SymPy üzerinde çalışıyorum . Bunun temel bir parçası, çok-prevision kayan nokta aritmetiği için bir kütüphane olan mpmath'tır . SymPy mpmath olmadan çalışmaz, alternatifi yoktur. Bu nedenle, başlangıçtan beri SymPy ile birlikte paketlenmiştir (her yeni sürüm içe aktarıldığında düzeltmek için genellikle küçük uyumsuzluklar olduğu söylendi). Ayrıca, mpmath geliştiricisinin SymPy gelişimine dahil olduğu belirtilmelidir. Artık mpmath'in ayrıştırılmasıyla ilgili bir sorun var, hepsini buradan okuyabilirsiniz .

Buradaki tartışmayı özetlemek gerekirse:

Unsurların:

• Python 3'e taşınması biraz daha kolay (küçük argüman IMHO)

• Dağıtımlar için daha kolay paketleme

• Kullanıcılara daha hızlı (güvenlik) özellik güncellemeleri

• "Ambalajlama ve elleçleme bağımlılıkları zor problemler ama çözüldü. Bu kesinlikle kendi işimizi yapmamız gereken bir alan değil."

Paketlemeye devam et:

• Kurulum. Linux'ta kolay, Mac'te zor ve Windows'ta çok zor. Su erişimi ve diğer sorunların olmaması.

• SymPy'nin ayrılmaz bir parçasıdır, yani sense onsuz çalışmaz (hiç)

• orada hiçbir başka paket, o mpmath iş yapabilirsiniz

• "Bir kullanıcı olarak senfoni indirdiğimde, sadece çalışmasını bekliyorum."

Bu benim özel durumum, ama iyi, genel bir cevap da veren bir yanıtı kabul ediyorum.

Yine başka bir cevap, ama en önemlisi olarak düşündüğüm (sadece kendi kişisel görüşüm), diğerleri de iyi cevaplar.

Lib'in ayrı ayrı paketlenmesi, uygulamanın güncellenmesine gerek kalmadan lib'in güncellenmesine izin verir. Diyelim ki lib'de bir hata var, sadece lib'i güncelleyebilmek yerine, tüm uygulamayı güncellemelisiniz. Bu, uygulamanızın sadece lib nedeniyle kodu değişmeden bir sürüm yumruya ihtiyacı olacağı anlamına gelir.

Bahsettiğiniz avantajların (güvenlik, paketleme, özellikler) yanı sıra, biraz daha düşünebilirim:

• İşlevselliği başka bir program için yararlı bulan birinin, onu bölme işini yapmasına gerek yoktur. Bu, projenizde işlevselliğin ilk etapta bir kütüphane şeklinde olup olmadığını bile biliyorsa. Bu ne kadar iyi tasarlandığına bağlıdır ... projeniz yeterince modüler ise.

• Bunun diğer projeler için yararlı olması durumunda, bu genel olarak disk kullanımının boyutunu azaltacaktır (örneğin, kodun sadece bir kopyası).

• Bu, kodunuzun kalitesini artıracak ve bazı (çok gerekli) yeniden düzenleme yapmaya zorlayacaktır. Yukarıdaki ilk noktada olduğu gibi bu, kodunuzun kalitesine de bağlıdır.

• Kütüphanenin kullanıcı sayısını arttırmak (eğer bölünmüşse) kütüphanenin daha genel olmasına yardımcı olur, bu da kalitesini artıracaktır.

Avantajlar açık olsa da, dağıtım kolaylığı, sizin durumunuzdaki programla birlikte nakliye kütüphanesi için ana argüman gibi görünmektedir.

Paketlemeye karşı birkaç argüman daha:

• Linux'ta, kitaplığınızın bağımlılıkları ile iyi çalışmasını sağlamak dağıtım yöneticisinin görevidir. Çoğu kullanıcı her durumda dağıtımın paket yöneticisini kullanarak kütüphaneyi indirir. Bagajı kullananlar genellikle kütüphaneyi yapılandırmak için zaman harcamayı umursamazlar.

• Windows ve Mac OS'de pip gibi Python paket yöneticileri genellikle zaten kullanılır, çünkü kitaplıkları elle yüklemek zahmetlidir.

• Google uygulama motoruna zorla dağıtım hakkında tartışmalar bile var, ancak tüm web çerçeveleri üzerinde çalışmaz. Birçoğu bile bağlantı gerektirir, kütüphaneler için disk alanı sınırlıdır ve sonuçta web uygulaması barındırma! Web uygulamasının sembolik matematik kullanması pek olası değildir.

• Bağımlılık yoksa veya yanlış sürüme sahipse kimse temiz hata iletileri görüntülemenizi engellemez.

• Program kendisinden daha zeki olduğunu düşündüğünde insanlar bundan sık sık nefret ederler. Kullanıcıların kendi sistemlerine bakmasına izin verin.

Uygun bir yol paket kütüphanenin varlığı için preinst testi olacaktır yükleyicisi pencerelerde ayrıştırılmış işlemek için ve mevcut değilse, yazılım yükleyici paketinde içerdiğini kütüphane paketinden yüklemek için teklif. Windows portları olan çoğu GTK uygulamasının bu hatlar boyunca bir şeyler yaptığından eminim - pidgin'in yaptığını biliyorum .

Bir beden herkese uymak zorunda değildir.

Kaynak dağıtımları için, gruplandırırsanız, birçok dağıtımdaki (en azından Debian ve Fedora miraslarının) paketleyicilerin, bu platformlar için paket ilkeleri paketlemeyi yasakladığı veya en azından kesinlikle cesaretini kırdığı için, paketlemeyi devre dışı bırakmak veya kaldırmak için ek çalışmalar yapmak zorundadır. Bu nedenle, demetleme yoluyla, aşağı akışınız için çok az fayda ile daha fazla iş yaratıyorsunuz. Bu argümanın ağırlığı olabilir mi?

İkili dağıtımlar (bunları sağlarsanız) her iki şekilde de gidebilir; demetleme, aşağı akış tarafından kullanılmadıkları için muhtemelen mantıklıdır.

Ancak, Windows ve Mac yükleyicileri için tam tersi karar verememenizin bir nedeni yoktur.

Paketleme ve bağımlılık paketleme dünyasında eski bir tartışmadır. Bu belge şu iki düşünce okulunu anlatır: http://www.aosabook.org/en/packaging.html