Kişisel bir Python projesini serbest bırakılabilir bir kütüphaneye dönüştürmek


28

Programcı değil akademik bir öğrenciyim ve araştırmamı desteklemek için Python programlarını kendi kullanımım için yazmakta uzun yıllara dayanan bir deneyime sahibim. En son projem de benim kadar birçokları için faydalı olacak ve açık kaynak kodlu bir Python kütüphanesi olarak yayınlamayı düşünüyorum.

Bununla birlikte, işleyen bir kişisel projeden başkaları tarafından acısız bir şekilde kurulabilen ve kullanılabilen bir kütüphaneye geçmenin önünde bazı engeller var gibi görünmektedir. Bu soru halka açıklamaya doğru çalışmaya başlamak için atmam gereken ilk adımlarla ilgili.

Şu anda, kütüphaneyi ve kütüphanenin kendisini kullanan kodumu içeren tek bir git deposuna sahibim ve bir şeyin kopması durumunda gitmeyi acil durum olarak geri al düğmesi olarak kullanıyorum. Bütün bunlar tek bir kullanıcı için gayet iyi çalışıyor ancak yayınlamak istersem kesinlikle uygun değil. Son olarak istediğim, kütüphanemin ayrı bir depoda olduğu ve başkaları tarafından kurulabilen pipve kararlı bir API'ye sahip olduğu.

Setuptools vb. Kullanmayı öğrenmek, muhtemelen yayınlamak istediğim bir noktada olduğum için çok zor değildir - benim sorunum bu noktaya gelmek için nasıl çalışmam gerektiğini bilmek.

Öyleyse sorum şu, bir Python kütüphanesi projesini kamu tüketimi için hazırlamaya başlamak için atılması gereken ilk adımlar nelerdir? Halka açık bir kütüphanenin yayınlanmasını sağlamak için dizin yapımı, git deposunu vb. Nasıl yeniden düzenlemeliyim?

Daha genel olarak, bu ilk kez denenirken yardımcı olduğu bilinen kaynaklar varsa çok yararlı olacaktır. En iyi uygulamalara ve hatalardan kaçınmaya vb. Yönelik işaretçiler de çok yardımcı olacaktır.

Bazı açıklama: Cari cevaplar çizgisinde bir soru hitap edilmektedir "nasıl benim Python kütüphanesi kullanımına başkaları için iyi bir hale getirebiliriz?" Bu faydalı, ancak sormayı düşündüğüm sorudan farklı.

Şu anda projemi bırakmak için uzun bir yolculuğun başlangıcındayım . Uygulamamın özü işe yarıyor (ve gerçekten iyi çalışıyor), ama önümdeki çalışma miktarından çok şaşırdım ve sürecin nasıl yönlendirileceğine dair rehberlik arıyorum. Örneğin:

  • Kütüphane kodum şu anda onu kullanan kendi etki alanına özgü koduma bağlı. Bir alt klasörde yaşıyor ve aynı git deposunu paylaşıyor. Sonunda, bağımsız bir kütüphaneye dönüştürülüp kendi havuzuna konması gerekecek, ancak bunu nasıl erteleyeceğimi bilmiyorum çünkü nasıl yapacağımı bilmiyorum. (Bir kütüphaneyi 'geliştirme modunda' nasıl kurarım, böylece onu nasıl düzenleyebilirim, ne de iki git reposunun nasıl senkronize tutulacağı.)

  • Dokümanlarım kısa, çünkü sonunda Sfenks veya başka bir araç kullanmam gerekeceğini biliyorum. Ancak bu araçların öğrenilmesi kolay görünmüyor, bu yüzden bu büyük bir alt proje haline geldi ve ben onu kullanmaya devam ediyorum.

  • Bir noktada onu paketlemek ve oldukça karmaşık olan bağımlılıkları izlemek için setuptools veya başka bir araç kullanmayı öğrenmem gerekiyor. Bunu şimdi yapmam gerekip gerekmediğinden emin değilim ve belgeler yeni bir kullanıcı için tam bir labirenttir, bu yüzden daha sonra yapmaya karar veriyorum.

  • Hiçbir zaman sistematik testler yapmak zorunda kalmamıştım, ancak kesinlikle bu proje için yapacağım, bu yüzden (i) projem için hangi metodolojinin doğru olduğunu bilecek testler hakkında yeterince bilgi edinmek zorundayım; (ii) benim seçtiğim metodoloji için hangi araçların mevcut olduğunu öğrenmek; (iii) seçilen aracımı kullanmayı öğren; (iv) projem için test takımları vb. uygulamak. Bu başlı başına bir proje.

  • Yapmam gereken başka şeyler de olabilir. Örneğin, jonrsharpe, daha önce hiç duymadığım git-flow, tox, TravisCI, virtualenv ve CookieCutter'dan bahseden yararlı bir bağlantı yayınladı . (Gönderi 2013'ten geliyor, bu yüzden hala ne kadar güncel olduğunu bulmak için biraz çalışmam gerekiyor.)

Bunları bir araya getirdiğinde çok fazla iş var, ama eminim ki takılı kalmaya devam edersem her şeyi halledebilirim ve acelem yok. Benim sorunum, her seferinde bir kez yapılabilecek yönetilebilir adımlara nasıl ayrılacağını bilmek.

Başka bir deyişle, sonunda serbest bırakılabilir bir ürüne ulaşmak için şimdi atmam gereken en önemli adımların hangileri olduğunu soruyorum. Boş bir hafta sonum varsa, bunlardan hangisine odaklanmalıyım? Hangi (eğer varsa) diğerlerinden izole edilerek yapılabilir, böylece her şeyi yapmaya gerek kalmadan en azından bir adım atabildim? Bu şeyleri öğrenmenin en etkili yolu nedir, böylece hala projenin kendisine odaklanmak için zamanım olacak. (Tüm bunların aslında benim işim değil hobi bir proje olduğunu akılda tutarak.) Yapmam gereken herhangi bir şey var mı , bu yüzden kendime çok fazla zaman ve çaba harcıyorum.

Tüm cevaplar büyük beğeni topluyor, ancak özellikle modern Python gelişimine atıfta bulunarak, bu proje yönetimi konularına odaklanan cevapları memnuniyetle karşılarım.



10
Bir kütüphanenin “vahşi doğaya” yayılmaya hazır olup olmadığını kontrol etmenin en iyi yolu, bir araştırma görevlisinden veya bir öğrenciden onu kullanmayı denemesi ve karşılaştıkları tüm zorlukları yazmasıdır. Sizi sürekli yardım almak zorunda kalmadan kullanabiliyorlarsa, kütüphane başkaları tarafından kullanılabilecek şekildedir.
Bart van Ingen Schenau

@ jonrsharpe, orada bir sürü süper faydalı bilgi var
Nathaniel

@BartvanIngenSchenau teşekkür ederim, o adıma yakın olduğumda kesinlikle bunu aklımda tutacağım. Şimdi "ilk adım" aşamasında, işe yarayan ancak serbest bırakılmaya hazır olmayan bir şeyi almaktan ve gelecekte serbest bırakılabilir olmasını sağlamak için şimdi nasıl bir şeyler yapmam gerektiğini merak ediyorum.
Nathaniel

3
Kütüphane için mutlaka tek başına bir git repo yapmalı ve sonra ilk müşteriniz olmalısınız. Projenizdeki kütüphaneyi, kaynağına bağlanma yerine, uygun bir kütüphane olarak kullanın.
Ian MacDonald

Yanıtlar:


22

Bir kütüphanenin kullanılmasını istiyorsanız, gerekli olduğunda bir setup.py eklemek en önemli adım değildir. Daha da önemlisi, dokümantasyon eklemek ve kitaplığınızın reklamını yapmaktır. İkinci nokta güçlü bir şekilde kütüphaneye bağlı olduğundan, dokümantasyona odaklanmama izin verin.

  1. Kütüphanen hakkında her şeyi biliyorsun. Ve bu problemli. Nasıl kurulacağını ve nasıl kullanılacağını zaten biliyorsun, pek çok şey sizin için sezgisel veya açık bir şekilde görülebilir. Ne yazık ki, aynı şeyler kullanıcılar için sezgisel değil ne de açık olabilir. Kütüphanenize bu konuda hiçbir şey bilmiyormuş gibi bakmaya çalışın ve daha da önemlisi, diğer insanlardan kullanmasını isteyin ve yaşadıkları tüm zorlukları tespit etmeye çalışın.

  2. Kütüphanenizin ne hakkında olduğunu İngilizce olarak açık bir şekilde açıklayın. Çok fazla kütüphane, herkesin onları bildiğini varsayar. Böyle olmadığında, kütüphanenin amacının ne olduğunu anlamak zor olabilir.

  3. Ayrıntılı teknik belgeler yazın, ancak kütüphanenizde bazı görevlerin nasıl yapılacağını gösteren kısa kod parçalarını da unutmayın. Çoğu geliştirici acele ediyor ve temel bir şeyi nasıl yapacağını anlamaya çalışmak için saat harcamak zorunda kalırlarsa, diğer kütüphanelere geçme eğiliminde olabilirler.

  4. İletişim bilgilerinizi ekleyin. Eğer kütüphaneniz bir başarı ise (ve kendi tecrübelerim bunun bilinmeyenler için bile geçerli olduğunu göstermiştir), insanlar onunla zorluklarla karşılaşırlar: ya bazı kısımları anlama ya da kullanmada hem hata hem de basitçe zorluklar. Kütüphanenizi geliştirmek için geri bildirimlerini almak genellikle yararlı olur: Bir sorun bildiren her kişi için, karşılaştığında, yalnızca başka bir kütüphaneye geçmeyi tercih eden yüzlerce kişi vardır.

Buna ek olarak:

  1. Kütüphanenizin Python 2 veya 3 veya her ikisiyle de çalışıp çalışmadığını netleştirin.

  2. Kitaplık Windows'ta çalışmıyorsa, bunu söyleyin.

  3. Resmi kuralları kullandığınızdan emin olun (kontrol etmek için pep8 kullanın). Değilse, açık bir şekilde açıklayın veya düzeltin.

  4. Kenar taşıma kasalarına dikkat edin. Kütüphaneniz yanlış bir türle veya desteklenmeyen bir değerle çağrıldığında, tam olarak neyin yanlış olduğunu İngilizce olarak söylemelisiniz. Yapmaması gereken, şifreli bir istisna oluşturmak için istifin on seviyesinden aşağıya inmek ve kullanıcının neyin yanlış gittiğini anlamasını sağlamak.


Teşekkürler, dokümantasyon kalitesinin bir proje haline getirdiği veya kırdığı konusunda tamamen hemfikirim. (Genellikle bir projenin kullanılıp kullanılmayacağına karar verirken kontrol edeceğim ikinci şey, son işlem tarihinden sonra). Projem için hangisine öğrenmeye yatırım yapmam gerektiğini nasıl söyleyebilirim?
Nathaniel,

3
@Nathaniel Sphinx kurulumu biraz zor, ancak fiili standart. Web üzerinde Sphinx belgelerine ev sahipliği yapmak için readthedocs.org kullanabilirsiniz. Sfenks, kütüphanenizdeki fonksiyonlardan ve modüllerdeki dokümanları kullanabilir. Alternatif olarak, yalnızca doc'ları benioku dosyasına yazın, ancak bu daha büyük projeler için hantal olur. Koruduğum Python projesi Sfenks dökümantasyonu için Github sayfalarını kullanıyor, bu da HTML dosyalarını işlemek zorunda olduğum anlamına geliyor.
amon

5
How can I tell which one I should invest in learning for my project?- yapmazsın. Makul görünen birini seçmek için biraz zaman harcıyorsunuz. Her karar için 40 seçeneğinizin olduğu bir javascript dev olarak, bunun doğru bir karar olduğuna söz veriyorum :)
aaaaaa

2

Yıllar geçtikçe, olgun kütüphanelerden daha az adil bir şekilde kullanmış olmanız, dağıtım aracınızı seçtikten sonra önemli bir öneridir: Kütüphaneniz etrafınızda bir topluluk oluşturabileceğiniz gerçekten yararlı bir şey yapıyor mu?

Kütüphane bağımlılıklarınızı tanımlayın.

Temiz bir ortama bir docket konteyner veya VM denemeye çalışın. Bu adımı, genellikle kişisel sorunlarla ilgili sorunlara neden olan benzersiz bir şeyler olduğu için çok önemli buluyorum.

Gelecekte kütüphaneyi kimin koruyacağını düşünün, birinin üç veya dört yıl boyunca evcil hayvan projesi olan bir kütüphaneye rastlamaktan daha sinir bozucu bir şey yoktur ve daha sonra güncel tutmak için gereken güncellemeleri alamaz.

Siz veya ekibiniz, kütüphaneyi test edilmiş ve belgelenmiş tutmaya yönelik bir taahhütte bulunmak isteyip istemediğinizi düşünün (birim testleri ve CI boru hatları denklemin bir parçası olmaya başlar).


2

Belki de kendi alanında olgun bir OSS projesi bulabilir ve kodunu bu projeye katkıda bulunabilirsin? Bunun gibi birkaç avantaj olabilir:

  • Katkınızı en üst düzeye çıkarabilirsiniz. Aslında, birçok "hobi" OSS projesi potansiyel olarak değerlidir ancak topluluk tarafından çok az kullanılmaktadır (bkz. @ReaddyEddy answer). Projeyi başlangıçta çizik hale getirmek, daha sonra sürdürmek, reklamını yapmak, uygun örnekler ve belgeler sunmak, vb.
  • Bahsettiğiniz teknik sorunların çoğu, olgun projede zaten çözülmüş olacaktı.
  • Kütüphaneniz OSS projesine değer katarsa, katkıda bulunanlar kodunuzu proje standartlarına getirmenize yardımcı olabilir. Böylece, emek tasarrufu ve deneyim kazanabilirsiniz. Ayrıca Sphinx, TravisCI, CookieCutter ve diğer teknik konular hakkında özel cevaplar alacaksınız.

Beğendiğiniz ve belki de kullanabileceğiniz ilgili bir OSS projesi varsa, neden bir sorun veya bir çekme isteği açmıyor ya da bakım verenlerle temasa geçiniz? (Başlamak için iyi bir yol mevcut bir sorunu çözmek olabilir.)


Teşekkürler, güzel bir fikir. Ancak, benim durumumda, kodumun entegre olabileceği mevcut bir paket yok. Benzer işlevselliğe sahip yerleşik bir OSS projesi var, ancak farklı teknolojilere dayanıyor ve özünde temelde farklı bir algoritma kullanıyor. (Sonuç olarak, sürümümde kolaylaşan bazı şeyler temelde imkansız.) Kodum için küçük ama potansiyel olarak özel bir izleyici kitlesi olduğundan eminim, ancak yeni bir yaklaşım olduğu için bunu yapmanın bir yolu olmadığını düşünüyorum. yeni bir proje olarak geliştirmekten başka mevcut.
Nathaniel

2

2019, en modern araçlarla başlamanızı şiddetle tavsiye ediyorum. Buna ihtiyacınız yok setup.py, bu Python topluluğundaki insanların kurtulmak istedikleri bir şey ve sonunda inanıyorum.

Şiir deneyin , pişman olmayacaksınız.


1
Cevap için teşekkür ederim. Şiire bir göz atacağım. Yine de şunu söylemek isterim ki, 2019’da yeni başlayanlar için en modern araçların gerçekte ne işe yaradığını görmek fevkalade zor. Eğer bilmiyorsanız, hangi araçların herkesin kullandığı ve aynı zamanda pek çok deneysel proje arasında yer alan fiili standart araç olduğunu söylemek çok zordur. Resmi belgeler bunlara ayak uyduramıyor ve geliştirme o kadar hızlı hareket ediyor ki bulduğum herhangi bir tanıtım malzemesinin güncel olmadığını garanti ediyor.
Nathaniel

Bunların hepsi, Şiirin, bakmam gerektiğini bulduğum üç veya dört aktif proje yerine, göz önünde bulundurmam gerektiğini söylediğin için teşekkür ederim . Bu, bu sorudan almayı umduğum bilgi türü.
Nathaniel

@Nathaniel Python "Ambalaj" hızla değişiyor (ve bu yüzden bunu yapmanın pek çok yolu var ve en iyisini bulmak zordur), ancak PEP 517, 518 birçok araç tarafından (Şiir gibi) uygulandı. çok korkunç değil. Şiirin mutlaka "en iyi" araç olmadığına dikkat edin, ama en azından en iyilerinden biri. Testandcode.com/52 adresini ziyaret edin , bu konuyla ilgili oldukça iyi bir fikir edineceksiniz .
laike9m

Teşekkürler, bu çok yardımcı oldu, şimdi dinliyorum. Belki de bütün bunlar demek oluyor ki, şu an için bir kenara ayırmalıyım ve diğer hususlara odaklanmalıyım (örneğin, dokümantasyon ve test için öğrenme araçları), çünkü altı ay içinde daha kararlı bir Python ambalaj ekosistemi olabilir.
Nathaniel

2

Bu sorduğunuz karmaşık bir soru ve Arseni'nin cevabını tamamen kabul ediyorum . İyi dokümantasyon çok önemli bir husustur. Kütüphanenizi hazırlayıp birkaç basit adımla çalıştırmayı başaramazsam, onu hemen oraya bırakıyorum (denemekten gerçekten endişeli olmadığım sürece).

Kesinlikle dikkate aldığınız bazı şeyler

  • Kütüphanenizi nasıl versiyonlandıracağınızı düşünün. Bir seviyeye geriye doğru uyumluluk ve rota boyunca da hata düzeltmeleri yapmak istiyorsunuz. Anlamsal versiyonlama hakkında bilgi edinin
  • Git'i nispeten doğrusal bir şekilde kullanıyorsunuz (geri almak için). Eğer aşina mısınız GIT'de dallanma . Gerçekten o kadar zor değil ve hayatı kolaylaştırıyor. Bir zamanlar dallara dokunuyorsun. Deponuz için bir dallanma modelini uyarlayın. Bu dallanma modelinin alakalı olduğunu düşündüğünüz parçaları seçin . Ayrıca bunu, kullandığınız havuzlardaki şubelerle karşılaştırın.
  • Lisanslama: Kütüphaneniz için bir lisans sağlamalısınız. Bu konuda hukuki bir uzman değilim, bu yüzden yalnızca ortak lisanslar arasındaki bu karşılaştırmaya ait bir linki paylaşabilirim . Bu seçimi hafifçe alma.
  • Bugtracker. Bu kullanıcının size hata raporları vermesini istiyorsunuz. Bu, kodun kalitesini artırmanıza yardımcı olur. Çözdüğünüz her hata için, test çerçevesi çalışmanıza gelecekte bir frenleme yapmaması için bir test ekleyin (regresyon testi). Özellik istekleri için bir hata takip sistemi kullanılabilir.
  • Kullanıcı katkıları Kullanıcı katkıları ister misiniz? Bunun genellikle açık kaynaklı ürünler üzerinde nasıl çalıştığından emin değilim, ancak kullanıcıların özellik dalları oluşturmasına izin verebileceğinizi hayal edebiliyorum. Github ile bunu çekme istekleriyle kontrol edebiliyor gibi görünüyorsun

Python ile ilgili hiçbir deneyimim olmadığından, bu yönde size hiçbir ipucu veremem. Bununla birlikte, uzak havuzunuzdaki her bir işlem tarafından tetiklenen tüm testleri otomatikleştirmek mümkündür (örneğin, Jenkins kullanarak ). Bununla birlikte, bunu ertelemeyi öneririm, çünkü önceden deneyim olmadan ayarlamak çok fazla iş.


2

Bunlar harika sorular.

Serbest bırakılabilir bir kütüphaneye doğru atılan önemli somut adımlar hakkında:

  • Kütüphane olacak dosyaları projenin geri kalanından ayırın.
    • Kütüphane kendi git deposuna girmelidir, ancak onu mevcut deponuzdaki ayrı bir üst seviye dizine koymak için yararlı bir ara adım bulabilirsiniz. Ayrı bir depo oluşturduğunuzda, projenizin geri kalanına bitişik olanları saklayın; ../librarybu sayede pip paketleme ve geliştirme modu adımlarına geçene kadar başvurabilirsiniz .
    • Projenin geri kalanından bu kütüphaneye erişimin genel API'sinden geçmesi gerekir. Ayrıştırmak için bazı bağımlılıklar bulabilirsiniz.
  • Kitaplığın API'sini belgelemek için artımlı olarak docstrings yazın.
    • Sonunda dokümanlar bir dokümantasyon aracına beslenir, ancak önemli iş API'yi açıklayan metni diğer kişilere yeterince ve yeterince açıklamaktır. Her seferinde bir kerede bir miktar doldurmak daha kolaydır ve kaba taslaklar yazarak ve daha sonra daha iyi açıklamalar ve örnekler akla geldiğinde geri dönerek çok daha iyi bir şekilde ortaya çıkacaktır.
    • API’nin bir bölümünü belgelendirmenin zor olduğunu düşünüyorsanız, API’nin bu bölümünün iyileştirilmesi için yeterli alanı olup olmadığını sorun. Daha basit olabilir mi? Daha düzenli mi? Çok mu genel? Çok mu uzman? Daha bilinen isimler kullanabilir miydi?
    • Belgeler, araçların kontrol edebileceği yapılandırılmış yorumları kullanarak argüman türlerini belgeleyebilir. Bununla ilgili gerçek belgeleri bulamadım, ancak PyCharm IDE bu dokümanları oluşturmaya yardımcı olacak ve yöntem çağrılarını düzenlerken hemen argüman türlerini kontrol edecektir.
    • Bundan bahseden PyCharm, geliştirici zamanından tasarruf etmek ve kod kalitesini artırmak için harika bir araçtır. Düzenlerken kodu kontrol etmek için "denetimler" yapacaktır, örneğin, mümkün olduğunda türleri kontrol etmek, eksik ve kullanılmayan ithalatları kontrol etmek, yinelenen yöntemler, PEP 8 stil hataları vb.
  • Birim testleri kullanmaya başlayın pytest. Piyasaya sürülmeden çok önce, birim testleri köşedeki durumlarda hatalar bularak ve kod değişikliklerinin bir şeyleri bozmadığına dair güven sağlayarak kendi gelişiminizde karşılığını verir. Yine, zamanla bunu inşa edebilirsiniz. Başlamak oldukça kolay.
  • Dosyaları ve sürümleri nasıl düzenlediklerini görmek için GitHub'da mevcut açık kaynaklı kitaplıkları (yaklaşık olarak aynı boyutta olan) inceleyin. Hata / sorun takibi ve istekleri nasıl karşıladıklarını izleyin. Eğer orada deneyiminiz yoksa, bu çok kişili proje organizasyon süreçlerinde deneyim sahibi olmak için bunlardan birine veya birkaçına katkıda bulunun. GitHub bu işlemler için iyi araçlara sahiptir. README.mdBelge dosyalarında en üst düzeyde ve herhangi bir dizinde ve bir lisans dosyası ile güzel şeyler yapar .
  • Kütüphane, API ve dokümantasyon hakkında geri bildirim almak için bir ortak çalışanı dahil edin.
    • Yayınladığınızda, tatildeyken hataları düzeltmek, kullanıcı sorularını yanıtlamak ve bu arada kitaplık yayınlama görevlerini bölmek için kod incelemeleriyle Çekme İsteği yapmaya başlamaya başlamak için bir veya daha fazla ortak çalışana sahip olmanıza yardımcı olur. ve proje yönetimi ve kütüphane tasarımı ile ek deneyim getirmek.
  • Şimdiye kadar lineer bir git taahhüt tarihi yapıyorsunuz. Sonunda, belirli düzeltmeler ve değişiklikler için "yayın dalları", bir yayına kadar kontrollü çalışma için "yayın dalları" ve birleştirme işlemine hazır olmayan çok kişili bir çalışma için "geliştirme dalları" kullanmak yararlı olacaktır. ana şubeye. Bu yüzden, bunu öğrenmek için bir iki gün ayırın ve bu git becerilerine güvenmeden önce pratik yapmaya başlayın. git çok esnek ve kullanışlıdır, ancak kullanıcı arayüzü dolandırılabilir .
    • Git şubeleri ve kullanımları hakkında okunacak bir yer Pro Git kitabında . Of birçok dalları kullanılmasına ilişkin yöntemler, sadece başlamak "sorunu dalları."
    • GitHub Desktop uygulaması şubeleri yönetmek için harika bir araçtır. Tüm değişiklikleri gözden geçirirken taahhüt mesajı yazmayı kolaylaştırdığı için taahhütlerde bulunmak için de harikadır.
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.