Praktik yang baik mengenai beberapa sistem manajemen paket


14

Beberapa bahasa pemrograman datang dengan sistem manajemen paket mereka sendiri, misalnya, dalam kasus R, install.packagesperintah bawaan menginstal dari repositori CRAN dan berurusan dengan dependensi.

Secara paralel, OS datang dengan sistem manajemen paket mereka sendiri, seperti aptperintah untuk distribusi Linux berbasis debian.

Saya telah memutuskan bahwa lebih baik menggunakan manajer paket distribusi, untuk menjamin bahwa semua yang ada di sistem saya akan kompatibel (lihat /programming//a/31293955/1878788 ).

Tetapi segera datang suatu hari ketika saya membutuhkan hal-hal yang tidak tersedia dengan cara ini. Misalnya, program bioinformatika yang tidak dikemas oleh distribusi saya akan memerlukan beberapa versi spesifik R. Kebetulan program tersebut tersedia melalui proyek bernama "bioconductor", yang tujuannya adalah menyediakan paket R untuk bioinformatika, memastikan bahwa paket akan kompatibel satu sama lain (lihat https://www.bioconductor.org/install/#why-biocLite ).

Jadi saya memutuskan untuk tidak menggunakan sistem manajemen pengemasan OS saya untuk R, dan menginstal semuanya melalui biocLiteperintah yang disediakan oleh proyek bioconductor.

Pendekatan ini berjalan lancar untuk beberapa waktu, sampai saya menemukan bahwa untuk menjaga ekosistem bioinformatika yang koheren, sehat, dan mudah dibangun kembali, beberapa orang telah memutuskan untuk menggunakan sistem manajemen paket konda. Proyek ini, yang disebut "bioconda" tidak hanya menyediakan paket R, tetapi hal-hal dari semua jenis bahasa, dengan kemungkinan untuk dengan mudah beralih versi, dan sebagainya (lihat https://bioconda.github.io/ ).

Saya kemudian memutuskan untuk menggunakan pendekatan ini, dan itu berjalan dengan lancar sampai saya membutuhkan paket R yang tidak disediakan oleh bioconda / conda. Seharusnya super mudah, tetapi upaya saya untuk membuat paket conda gagal, maka saya mencoba menginstal paket menggunakan cara bioconductor, dan gagal lagi. Saya mendapat kesan bahwa entah bagaimana instalasi R yang salah sedang digunakan oleh mekanisme pembangunan paket. Jadi saya memutuskan untuk menghapus instalasi konda saya (yang masih sangat muda) dan kembali ke ekosistem biokonduktor saya.

Saya bertanya-tanya berapa lama saya harus melompat dari satu pendekatan ke pendekatan lainnya. Apakah ada praktik umum yang baik tentang bagaimana menangani berbagai tingkat, paket, dan tumpang tindih manajemen paket?

Sunting (14/09/2017) : Namun pilihan lain yang saya pertimbangkan adalah menggunakan manajer paket tingkat-OS alternatif, seperti Guix atau Nix .


1
Proyek Fedora memiliki pedoman untuk kemasan program R . Paket R RPM di Fedora, RHEL dan CentOS umumnya akan mengikuti ini.
Michael Hampton

Jawaban:


13

Saya tidak yakin apa yang tersedia untuk R (mendengar tentang REnv), tetapi untuk Python saya telah memutuskan pada pendekatan pragmatis bahwa setiap pengguna bertanggung jawab atas lingkungan Python mereka dengan pyenv(sama berlaku untuk Perl dengan perlbrewdan Ruby dengan RVM). Dengan begitu, pengguna dapat menciptakan lingkungan optimal mereka sendiri untuk setiap proyek tanpa bantuan saya ( pyenvmengelola instalasi Python dan kemudian Anda dapat menggunakan pipuntuk menginstal modul lokal untuk instalasi Python tertentu).

Paket sistem hanya digunakan untuk kebutuhan sistem.


0

Biasanya lebih baik menggunakan manajer paket sistem. Tetapi jika Anda menggunakan bahasa modern, yang berkembang cepat, distribusi stabil tidak akan menyertakan paket dan versi baru. Dan paket yang tidak terlalu populer tidak akan pernah bisa dimasukkan dalam repositori.

Jadi saya katakan, cara terbaik dalam hal ini adalah menggunakan fungsi bawaan bahasa. Jika R-pencipta akan membuat alat resmi untuk mengelola paket, itu akan bagus, tetapi menggunakan alat non-resmi agak berisiko.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.