Paket python sering di-host di repositori banyak distribusi. Setelah membaca tutorial ini , secara khusus bagian berjudul "Apakah Anda benar-benar ingin melakukan ini" Saya telah menghindari menggunakan pip dan lebih suka menggunakan repositori sistem, hanya beralih ke pip ketika saya harus menginstal paket yang tidak ada dalam repositori.

Namun, karena ini adalah metode instalasi yang tidak konsisten, apakah lebih baik hanya menggunakan pip? Apa manfaat / pencela menggunakan pip atas repositori sistem sendiri untuk paket yang tersedia di kedua tempat?

Tautan yang saya sertakan menyatakan

Keuntungan dari selalu menggunakan paket standar Debian / NeuroDebian, adalah bahwa paket-paket tersebut diuji dengan cermat agar kompatibel satu sama lain. Paket Debian merekam dependensi dengan perpustakaan lain sehingga Anda akan selalu mendapatkan perpustakaan yang Anda butuhkan sebagai bagian dari instalasi.

Saya menggunakan lengkungan. Apakah ini yang terjadi dengan sistem manajemen paket lain selain apt?

Kerugian terbesar yang saya lihat dengan menggunakan pipuntuk menginstal modul Python pada sistem Anda, baik sebagai modul sistem atau sebagai modul pengguna, adalah bahwa sistem manajemen paket distribusi Anda tidak akan tahu tentang mereka. Ini berarti bahwa mereka tidak akan digunakan untuk paket lain yang membutuhkannya, dan yang mungkin ingin Anda instal di masa depan (atau yang mungkin mulai menggunakan salah satu modul tersebut setelah peningkatan); Anda kemudian akan berakhir dengan kedua pip- dan modul yang dikelola distribusi versi, yang dapat menyebabkan masalah (saya bertemu dengan contoh lain baru-baru ini ). Jadi, pertanyaan Anda akhirnya menjadi proposisi semua-atau-tidak sama sekali: jika Anda hanya menggunakanpip untuk modul Python, Anda tidak bisa lagi menggunakan manajer paket distribusi Anda untuk apa pun yang ingin menggunakan modul Python ...

Saran umum yang diberikan di halaman yang Anda tautkan sangat baik: cobalah untuk menggunakan paket distribusi Anda sejauh mungkin, hanya gunakan pipuntuk modul yang tidak dikemas, dan ketika Anda melakukannya, lakukan dalam pengaturan pengguna Anda dan bukan sistem- lebar. Gunakan lingkungan virtual sejauh mungkin, khususnya untuk pengembangan modul. Khususnya pada Arch, Anda seharusnya tidak mengalami masalah yang disebabkan oleh modul yang lebih lama; bahkan pada distribusi di mana itu bisa menjadi masalah, lingkungan virtual menghadapinya dengan cukup mudah.

Itu selalu layak mempertimbangkan bahwa perpustakaan distribusi dan paket modul dikemas terutama untuk penggunaan paket lain dalam distribusi; memiliki mereka di sekitar adalah efek samping yang bagus untuk pengembangan menggunakan perpustakaan dan modul itu, tapi itu bukan kasus penggunaan utama.

TL; DR

• gunakan pip(+ virtualenv) untuk hal-hal (libs, frameworks, mungkin alat dev) proyek Anda (yang Anda kembangkan) gunakan
• gunakan manajer paket untuk aplikasi yang Anda gunakan (sebagai pengguna akhir)

Ketergantungan pengembangan

Jika Anda mengembangkan perangkat lunak dengan Python, Anda akan ingin menggunakan pipsemua dependensi proyek, baik dependensi runtime, dependensi build-time atau hal-hal yang diperlukan untuk pengujian otomatis dan pemeriksaan kepatuhan otomatis (linter, style checker, pemeriksa tipe statis) ...)

Ada beberapa alasan untuk ini:

• Ini memungkinkan Anda untuk menggunakan virtualenv (baik secara langsung atau melalui virtualenvwrapper atau pipenv atau cara lain) untuk memisahkan dependensi dari proyek yang berbeda satu sama lain dan untuk mengisolasi aplikasi python yang Anda gunakan "dalam produksi" (sebagai pengguna) dari shenanigans eksotis (atau bahkan hanya ketidakcocokan) yang mungkin terjadi dalam pengembangan.
• Ini memungkinkan Anda untuk melacak semua dependensi proyek dalam file requirements.txt(jika proyek Anda adalah aplikasi) atau setup.py(jika proyek Anda adalah pustaka atau kerangka kerja) file. Ini dapat diperiksa ke dalam kontrol revisi (misalnya Git) bersama dengan kode sumber, sehingga Anda selalu tahu versi kode Anda bergantung pada versi dependensi Anda.
• Hal di atas memungkinkan pengembang lain untuk berkolaborasi dalam proyek Anda bahkan jika mereka tidak menggunakan distribusi Linux yang sama atau bahkan tidak pada sistem operasi yang sama (jika dependensi yang digunakan juga tersedia di Mac dan Windows atau apa pun yang kebetulan mereka gunakan, yaitu)
• Anda tidak ingin pembaruan otomatis dari manajer paket sistem operasi Anda untuk memecahkan kode Anda. Anda harus memperbarui dependensi Anda, tetapi Anda harus melakukannya secara sadar dan pada waktu yang Anda pilih, sehingga Anda dapat siap untuk memperbaiki kode Anda atau memutar kembali pembaruan. (Yang mudah jika Anda melacak deklarasi ketergantungan lengkap di sistem kontrol revisi Anda, bersama dengan kode Anda.)

Jika Anda merasa perlu memisahkan dependensi langsung dan tidak langsung (atau membedakan antara rentang versi yang dapat diterima untuk dependensi dan versi aktual yang digunakan, lih. "Versi menyematkan") melihat ke dalam pip-tools dan / atau pipenv. Ini juga akan memungkinkan Anda untuk membedakan antara membangun dan menguji dependensi. (Perbedaan antara dependensi build dan runtime mungkin dapat dikodekan dalam setup.py)

Aplikasi yang Anda gunakan

Untuk hal-hal yang Anda gunakan sebagai aplikasi normal dan yang kebetulan ditulis dengan Python, pilih manajer paket sistem operasi Anda. Itu akan memastikan tetap up-to-date dan kompatibel dengan hal-hal lain yang diinstal oleh manajer paket. Sebagian besar distribusi Linux juga akan menyatakan bahwa mereka tidak mendistribusikan malware apa pun.

Jika sesuatu yang Anda butuhkan tidak tersedia di repo paket default distribusi Anda, Anda dapat memeriksa repo paket tambahan (misalnya launchpad distro berbasis deb) atau piptetap menggunakan . Jika yang terakhir, gunakan --useruntuk menginstal ke dalam rumah pengguna Anda daripada seluruh sistem, sehingga Anda cenderung untuk merusak instalasi Python Anda. (Untuk hal-hal yang hanya perlu sementara atau jarang, Anda bahkan dapat menggunakan virtualenv.)

Alasan lain untuk pergi dengan manajer paket adalah bahwa pembaruan akan diterapkan secara otomatis yang sangat penting untuk keamanan. Pikirkan jika paket kacang yang digunakan Equifax telah diperbarui secara otomatis melalui keamanan yum-cron, peretasan mungkin tidak terjadi.

Pada kotak dev pribadi saya, saya menggunakan Pip, di prod saya menggunakan paket.

Jika kita berbicara tentang menginstal paket python untuk digunakan dalam kode yang Anda tulis, gunakan pip.

Untuk setiap proyek yang sedang Anda kerjakan, buat lingkungan virtual, dan kemudian hanya gunakan pip untuk menginstal hal-hal yang dibutuhkan proyek. Dengan begitu, Anda menginstal semua perpustakaan yang Anda gunakan dengan cara yang konsisten, dan semuanya terkandung dan tidak mengganggu apa pun yang Anda instal melalui manajer paket Anda.

Jika Anda berencana untuk merilis kode python, biasanya, Anda akan menambahkan setup.pyatau requirements.txtke proyek Anda, yang akan memungkinkan pip untuk secara otomatis mendapatkan semua dependensinya. Mengizinkan Anda dengan mudah membuat atau menciptakan kembali lingkungan virtual untuk proyek itu.

Ringkasan

Ada tiga kategori umum modul yang Anda hadapi:

1. Program-program pendukung yang diinstal untuk semua pengguna dengan sistem paket OS. (Ini bahkan mungkin termasuk alat dan perpustakaan yang digunakan oleh orang-orang yang memprogram dalam Python; lihat di bawah ini.) Untuk ini Anda menggunakan paket OS di mana Anda bisa, dan pipmenginstal ke direktori sistem jika diperlukan.
2. Program-program pendukung yang diinstal oleh pengguna tertentu hanya untuk penggunaannya sendiri, dan juga untuk aspek-aspek tertentu dari penggunaan Python "sehari-hari" sebagai bahasa scripting. Untuk ini dia menggunakan pip --user, mungkin pyenv atau pythonz , dan alat dan taktik serupa.
3. Mereka yang mendukung pengembangan dan penggunaan aplikasi tertentu. Untuk ini, Anda menggunakan virtualenv(atau alat serupa).

Setiap level di sini mungkin juga mendapatkan dukungan dari level sebelumnya. Sebagai contoh, pengguna kami di (2) mungkin mengandalkan juru bahasa Python yang diinstal melalui paket OS.

Mempelajari lebih detail:

Program dan Paket Sistem

Program yang ditulis dengan Python yang Anda ingin "jalankan" itu mudah: cukup gunakan alat instal OS dan biarkan mereka membawa apa pun yang mereka butuhkan; ini tidak berbeda dengan program non-Python. Ini kemungkinan akan membawa Python tools / libraries (seperti interpreter Python itu sendiri!) Yang mungkin mulai diandalkan oleh pengguna di komputer Anda; ini bukan masalah selama mereka memahami ketergantungan dan, idealnya, tahu cara alternatif untuk menanganinya pada host yang tidak menyediakan dependensi tersebut.

Contoh umum dan sederhana dari ketergantungan seperti itu adalah beberapa skrip pribadi saya ~/.local/bin/yang dimulai dengan #!/usr/bin/env python. Ini akan berfungsi dengan baik (asalkan berjalan di bawah Python 2) pada RH / CentOS 7 dan sebagian besar (tetapi tidak semua) menginstal Ubuntu; mereka tidak akan menggunakan instalasi Debian dasar atau Windows. Meskipun saya tidak menyukai lingkungan pribadi saya yang memiliki banyak ketergantungan pada paket OS (saya bekerja pada sejumlah OS yang berbeda), sesuatu seperti ini menurut saya cukup dapat diterima; rencana cadangan saya pada host langka yang tidak memiliki sistem Python dan tidak bisa mendapatkannya adalah untuk pergi dengan sistem Pengguna seperti yang dijelaskan di bawah ini.

Orang yang menggunakan sistem juru bahasa python juga biasanya tergantung pada sistem pip3. Itu tentang di mana saya biasanya menarik garis pada dependensi sistem saya; semuanya dari virtualenvdepan saya berurusan dengan diri saya sendiri. (Misalnya, skrip aktivasi standar saya bergantung pada apa pun pip3atau yang pipada di jalur, tetapi mengunduh salinannya sendiri virtualenvuntuk bootstrap lingkungan virtual yang dibuatnya.

Yang mengatakan, mungkin ada keadaan di mana sangat masuk akal untuk membuat lebih banyak lingkungan pengembangan tersedia. Anda mungkin memiliki antarmuka Python ke dalam paket yang kompleks (seperti DBMS) di mana Anda ingin menggunakan versi sistem itu dan Anda merasa yang terbaik adalah Anda juga membiarkan sistem memilih kode pustaka Python tertentu yang akan Anda gunakan untuk berbicara dengannya. Atau Anda mungkin menggunakan banyak host dengan lingkungan pengembangan dasar untuk kelas Python, dan merasa lebih mudah untuk mengotomatisasi dengan paket sistem standar.

Program dan Paket "Pengguna Sehari-hari"

Pengguna mungkin memiliki pustaka atau program Python yang tidak cocok dengan lingkungan virtual karena mereka ingin membantu menciptakan lingkungan virtual di tempat pertama (misalnya, virtualenvwrapper ) atau mereka hal-hal yang biasa Anda gunakan dari baris perintah bahkan ketika melakukan pekerjaan non-Python. Bahkan jika mereka memiliki kemampuan untuk menginstal versi sistem ini, mereka mungkin merasa lebih nyaman menginstalnya sendiri (misalnya, karena mereka ingin menggunakan versi terbaru dari alat dan dependensinya).

Umumnya pip --userapa yang akan digunakan orang untuk ini, meskipun dependensi tertentu, seperti interpreter Python itu sendiri, memerlukan sedikit lebih dari itu. pyenv dan pythonz berguna untuk membangun penerjemah pribadi (apakah dipasang ~/.local/binsebagai penerjemah default atau tidak), dan tentu saja kita selalu bisa membangun "dengan tangan" dari sumber jika perpustakaan dev tersedia.

Saya mencoba untuk menjaga set minimal hal-hal yang diinstal di sini: virtualenvwrapper (karena saya menggunakannya terus-menerus) dan mungkin versi terbaru dari pip. Saya mencoba untuk menghindari dependensi di luar perpustakaan standar atau pada Python 3 untuk skrip pribadi yang saya tulis untuk digunakan di banyak host. (Meskipun kita akan melihat berapa lama saya bisa bertahan dengan itu karena saya semakin banyak memindahkan skrip pribadi ini ke Python.)

Pengembangan Aplikasi dan Lingkungan Runtime yang terpisah

Ini adalah hal virtualenv yang biasa. Untuk pengembangan Anda hampir selalu harus menggunakan virtualenv untuk memastikan bahwa Anda tidak menggunakan dependensi sistem, atau sering lebih dari satu untuk menguji terhadap versi Python yang berbeda.

Lingkungan virtual ini juga baik untuk aplikasi dengan banyak dependensi di mana Anda ingin menghindari mencemari lingkungan pengguna Anda. Misalnya saya biasanya membuat virtualenv untuk menjalankan notebook Jupyter dan sejenisnya.