PyPI dan pemilihan pustaka

PyPI menerima package dari siapa pun, sehingga kualitas di antara package yang tersedia tidak seragam. Package yang keliru dipilih membebani proyek dengan error yang lama tidak tertangani, dokumentasi usang, atau lisensi yang membatasi pemakaian. Topik ini membahas kriteria menilai package pihak ketiga dari sisi pemeliharaan, dokumentasi, lisensi, dan ketergantungannya, beserta cara membaca metadata, yaitu data rangkuman seperti versi dan lisensi, pada package yang sudah terpasang di lingkungan.

Sumber informasi pada halaman package#

Setiap package di PyPI memiliki halaman proyek yang menjadi titik awal penilaian. Halaman itu menampilkan nama dan versi terbaru beserta tanggal rilisnya, deskripsi panjang yang biasanya berupa hasil render README dari repository-nya, serta tautan menuju repository dan dokumentasi. Klasifikator pada halaman yang sama menyebut topik, lisensi, dan versi Python yang didukung. Tautan unduhan untuk setiap versi lama juga tetap tersedia, sehingga riwayat rilis dapat ditelusuri ke belakang.

Halaman proyek juga memuat peringatan yang perlu dibaca dengan saksama. Package yang dihentikan pengembangnya ditandai deprecated, sedangkan rilis yang ditarik karena kesalahan ditandai yanked, dan kedua tanda itu tampil jelas pada daftar versinya. Tanggal rilis terakhir pada halaman langsung menunjukkan apakah package masih dirawat ataukah sudah lama tidak disentuh. Informasi pada halaman baru benar-benar lengkap apabila dipadukan dengan isi repository-nya, yang dibahas pada bagian berikutnya.

Kriteria pemeliharaan#

Package yang baik dipelihara secara teratur, dan pemeliharaan itu dapat dibaca dari jejak yang ditinggalkan pengembangnya. Empat pertanyaan berikut memandu pemeriksaan tersebut.

Rilis yang jarang tidak selalu buruk, karena package yang sudah stabil memang jarang membutuhkan perubahan. Yang membedakan package stabil dari package terbengkalai adalah tanggapan terhadap masalah, yaitu apakah issue tentang versi Python terbaru mendapat jawaban atau justru menumpuk tanpa disentuh. Ketergantungan pada satu orang tanpa penerus juga berisiko, karena pemeliharaan berhenti bersamaan dengan berhentinya minat pribadi tersebut. Apabila dua kandidat package sama-sama memenuhi kebutuhan, kandidat dengan jejak pemeliharaan yang lebih merata biasanya menjadi pilihan yang lebih aman.

Kriteria dokumentasi dan antarmuka#

Dokumentasi menentukan seberapa cepat package dapat dipakai dengan benar. Tanda dokumentasi yang matang antara lain halaman mulai cepat yang langsung berfungsi ketika di-copy-paste. Referensi API perlu menjelaskan parameter dan nilai kembalian setiap fungsi publik, sedangkan contoh perlu mencakup kasus yang lebih rumit dari sekadar pengenalan. README yang hanya berisi satu cuplikan tanpa referensi lanjutan menandakan dokumentasi masih berada pada tahap awal.

Kualitas antarmuka juga dapat dibaca dari kode sebelum package dipasang. Adanya type hint, yaitu catatan tipe data pada deklarasi fungsi, membantu editor menyarankan parameter yang benar dan membantu pemeriksa tipe menangkap pemakaian yang keliru. Penomoran versi yang konsisten memudahkan menilai seberapa besar perubahan antarversi, sedangkan changelog yang menyebut perubahan yang tidak kompatibel secara jelas membuat migrasi dapat direncanakan. Package dengan antarmuka yang stabil biasanya mencantumkan penanda semacam itu pada dokumentasinya, dan keterangan tersebut layak dibaca sebelum kode produksi ditulis.

Lisensi dan ketergantungan#

Lisensi menentukan apa yang boleh dilakukan terhadap kode package. Lisensi permissive seperti MIT, BSD, dan Apache-2.0 memberi keleluasaan luas untuk menggunakan dan menyebarkan kode, dengan syarat dasar berupa penyertaan pemberitahuan hak cipta aslinya. Apache-2.0 menambahkan ketentuan pemberian lisensi paten. Lisensi copyleft seperti GPL membawa kewajiban yang berlaku juga pada kode yang menggabungkannya, sehingga penggunaannya pada produk tertutup perlu diteliti sejak awal dan bukan sesudah integrasi selesai.

Lisensi sebuah package tercatat pada metadata-nya, dan metadata package yang sudah terpasang dapat dibaca tanpa koneksi jaringan melalui modul importlib.metadata.

from importlib import metadata

for nama in ("httpx", "requests"):
    info = metadata.metadata(nama)
    print(nama)
    print("Versi:", info["Version"])
    print("Lisensi:", info["License"])
    print("Ringkasan:", info["Summary"])

httpx
Versi: 0.28.1
Lisensi: BSD-3-Clause
Ringkasan: The next generation HTTP client.
requests
Versi: 2.32.5
Lisensi: Apache-2.0
Ringkasan: Python HTTP for Humans.

Metadata tersebut berasal dari package itu sendiri, yaitu bidang yang sama yang dibaca perintah pip show. Selain lisensi, jumlah ketergantungan turunan juga layak dinilai, karena setiap ketergantungan menambah permukaan pembaruan dan risiko konflik versi.

from importlib import metadata

dist = metadata.distribution("requests")
print(len(dist.requires))
for syarat in dist.requires:
    print(syarat)

6
charset_normalizer<4,>=2
idna<4,>=2.5
urllib3<3,>=1.21.1
certifi>=2017.4.17
PySocks!=1.5.7,>=1.5.6; extra == "socks"
chardet<6,>=3.0.2; extra == "use-chardet-on-py3"

Empat baris pertama adalah ketergantungan inti yang selalu terpasang, sedangkan dua baris terakhir memuat penanda extra ==, yang berarti ketergantungan itu hanya terpasang bila diminta secara khusus. Setiap syarat juga memuat batas versi, sehingga pip memilih versi yang cocok tanpa melanggar batas tersebut. Package dengan ketergantungan inti yang pendek lebih mudah dipelihara, terutama pada lingkungan yang mengatur perubahan versi secara ketat.

Menguji kecocokan sebelum mengadopsi#

Penilaian di atas belum menguji apakah package cocok dengan masalah yang sedang dikerjakan, dan pengujian itu sebaiknya dilakukan pada lingkungan terisolasi. Untuk eksperimen, virtual environment baru disiapkan, package dipasang di sana, lalu potongan kecil kode produksi dijalankan terhadap data sungguhan yang bentuknya mirip pekerjaan sehari-hari. Data uji yang berat atau tidak lazim sering menyingkap keterbatasan yang tidak terlihat pada contoh dokumentasi.

Perbandingan antar kandidat juga sebaiknya dilakukan sebelum satu pun dipilih. Dua sampai tiga kandidat diuji dengan skenario yang sama, lalu hasilnya dinilai dari keterbacaan API, kelengkapan error yang ditimbulkannya, dan seberapa besar kode pembungkus yang dibutuhkan agar cocok dengan program. Pustaka standar tetap menjadi pembanding pertama, karena kebutuhan yang sudah terjawab oleh pustaka standar tidak menuntut ketergantungan tambahan sama sekali. Apabila pilihan sudah mantap, alasan pemilihannya beserta kandidat yang kalah layak dicatat pada dokumentasi proyek agar keputusan itu dapat dinilai ulang di kemudian hari.

Kesalahan umum#

Kesalahan pertama adalah menilai package hanya dari popularitasnya. Jumlah unduhan yang tinggi dapat merupakan warisan package lama yang masih terpasang di banyak mesin, padahal pemeliharaannya sudah berhenti. Popularitas tetap menjadi sinyal yang layak dibaca, tetapi pemeriksaan tanggal rilis terakhir dan tanggapan atas issue mendahuluinya.

Kesalahan kedua adalah menunda pemeriksaan lisensi sampai integrasi selesai. Apabila lisensinya ternyata copyleft dan proyek membatasi penyebaran kode, hasil kerja yang sudah matang harus ditulis ulang dengan package lain. Pemeriksaan lisensi hanya memerlukan sepuluh detik di awal, sedangkan penulisan ulang memakan waktu berminggu-minggu.

Kesalahan ketiga adalah memasang package tanpa batas versi pada berkas dependensi. Pemasangan pertama mengambil versi terbaru yang cocok, tetapi pemasangan pada bulan berikutnya bisa mengambil versi yang berbeda dan memunculkan error yang tidak pernah ada saat pengujian. Penentu versi pada requirements.txt, yang dibahas pada topik virtual environment, mengikat perilaku lingkungan agar tetap dapat direproduksi.

Ringkasan#

• Halaman proyek di PyPI menyediakan tanggal rilis, tautan repository, klasifikator, dan tanda deprecated atau yanked yang menjadi bahan penilaian awal.
• Kriteria pemeliharaan membaca kemutakhiran rilis dan tanggapan atas issue, sedangkan kriteria dokumentasi membaca README, referensi API, dan type hint.
• Lisensi permissive seperti MIT, BSD, dan Apache-2.0 memberi keleluasaan luas, sedangkan lisensi copyleft membawa kewajiban yang perlu dipelajari sejak awal.
• Modul importlib.metadata membaca versi, lisensi, dan daftar ketergantungan package yang terpasang tanpa koneksi jaringan.

Referensi#

• Python Package Index — Python Software Foundation — Repositori package Python yang menjadi sumber utama package pihak ketiga.
• importlib.metadata — Python Software Foundation — Dokumentasi modul pembaca metadata package yang dipakai pada contoh.
• pip show — Python Packaging Authority — Perintah pip untuk menampilkan metadata package yang terpasang.
• SPDX License List — SPDX — Daftar lisensi perangkat lunak beserta kode singkatnya, termasuk MIT, BSD, dan Apache-2.0.