Latar Belakang

Saya menggunakan emacs setiap hari, tetapi kebanyakan untuk menyelesaikan sesuatu. Saya tidak terlalu suka mengubahnya daripada menambahkan paket dan saya tidak suka pemecahan masalah. Saya ingin emacs memudar ke latar belakang seperti OS yang baik dan hanya melanjutkan hal-hal. Beberapa waktu yang lalu saya menemukan bahwa el-getmemungkinkan saya untuk menginstal paket yang saya butuhkan yang tidak tersedia dengan package.eldan juga memberi saya lebih banyak kontrol seperti memilih maintcabang mode Org daripada tepi pendarahan yang dapat menyebabkan masalah sementara. Sekarang saya tidak yakin apakah saya harus menggunakan el-getatau tidak.

Pertanyaan

el-gettampaknya menjadi solusi hebat untuk berbagai repositori dan peretasan emacs di luar sana. Ini menawarkan kemampuan yang sama sekali tidak mungkin dengan package.el. Sekarang bahwa package.eldalam versi emacs ( >=24.4) yang lebih baru mendukung banyak repositori, untuk apa kasing el-getdan alternatif serupa dengan pengelola paket bawaan emacs?

package package-repositories

— snth
sumber

2

Lihat juga: quelpa . Jawaban singkatnya adalah: Tentu saja, masih ada paket yang tidak menggunakan ELPA / MELPA / Marmalade. Jika Anda membutuhkannya, Anda masih bisa mendapatkannya tanpa peretasan yang mengerikan el-getdan sejenisnya.

— PythonNut

8

Ada hal-hal yang masih mustahil dengan ELPA, dan ada hal-hal yang akan selalu mustahil dengan ELPA, karena mereka tidak cocok dengan konsep ELPA: Anda tidak akan pernah dapat menginstal komit tertentu dengan hash dari forked gudang. Demikian juga, Anda tidak akan pernah bisa menerapkan tambalan lokal khusus ke paket sebelum menginstalnya. Fitur-fitur ini hanya di luar lingkup ELPA, dan jika Anda membutuhkannya, Anda harus menggunakan manajer paket alternatif.

Saya pikir, el-get itu semacam solusi warisan saat ini. Mengingat bahwa ELPA telah menjadi manajer paket standar de-facto untuk Emacs, manajer paket alternatif harus berintegrasi mulus dengan ELPA. el-get, bagaimanapun, tidak mengekspos paket-paketnya sendiri ke ELPA, yang berarti bahwa paket-paketnya sepenuhnya tidak terlihat oleh paket-paket ELPA dan ELPA tidak pernah dapat bergantung pada paket-paket el-get, dengan implikasi yang jelas untuk manajemen ketergantungan.

Jika Anda membutuhkan fitur di luar ELPA, Anda sekarang harus melihat QUELPA daripada el-get.

— lunaryorn
sumber

"Jika mereka tidak melakukannya, mereka tidak akan repot-repot merawatnya." Tujuannya mungkin hanya ego pengembang.

— T. Verron

Akan menjadi ego yang perkasa, yang bisa dengan mudah menarik komunitas sebesar yang masih ada, dan QUELPA dengan cepat memperoleh :)

— lunaryorn

Saya berkomentar secara umum, tentu saja. ;)Untuk spesifik dari paket yang ada, jawaban Anda, di luar pernyataan akal sehat, membuat titik kuat dengan menunjukkan tujuan el-get dan quelpa.

— T. Verron

@ T. Veron Ya, poin diambil. Saya telah menghapus pernyataan itu, itu adalah hal yang bodoh untuk dikatakan. Maaf.

— lunaryorn

@Lunaryorn dengan

el-get, however, does not expose its own packages to ELPA, meaning that **its packages** are entirely invisible to ELPA and ELPA

maksudmu hal-hal yang diinstal oleh el-get, kan?

— toogley

6

Saya telah menulis manajer paket baru untuk Emacs straight.el, yang mencoba untuk memperbaiki semua solusi manajemen paket yang ada. Ada bagian yang luas dalam straight.eldokumentasi tentang perbandingan dengan manajer paket lain , tetapi di sini adalah ringkasan yang sangat singkat:

package.elmengunduh tarbal buram dari server pusat, tanpa opsi untuk memilih versi tertentu dari suatu paket, dan tidak memungkinkan Anda untuk membuat perubahan lokal pada paket Anda; berkontribusi perubahan ke hulu tidak mungkin. straight.elklon Git repositori dengan cara yang terdesentralisasi (tetapi secara otomatis menggunakan resep dari MELPA , GNU ELPA , dan EmacsMirror , jika Anda mau), dan memungkinkan Anda untuk membuat perubahan lokal sewenang-wenang kepada mereka, melakukan perubahan itu, dan berkontribusi di hulu. Ini dapat dilakukan secara manual, atau Anda dapat menggunakan operasi manajemen repositori massal terintegrasi. Perubahan pada paket Anda terdeteksi secara otomatis, dan pembuatan ulang manual tidak diperlukan. Selanjutnya,straight.el mendukung reproduksibilitas lengkap untuk konfigurasi Emacs Anda, karena memungkinkan Anda untuk menulis file kunci revisi yang menyertakan hash Git dari semua paket Anda.
Quelpa dan Cask keduanya berdasarkan package.el, dan mewarisi banyak kelemahan yang sama. Misalnya, Tong tidak memiliki konsep menginstal versi tertentu dari paket. Quelpa melakukannya, tetapi itu mengharuskan Anda mengubah kode hasit Git ke file init Anda. straight.eleschews package.elsepenuhnya, menggantikan semua fungsionalitas intinya dengan desain terpadu yang disesuaikan dengan banyak kasus penggunaan lainnya.
el-get memiliki keuntungan bahwa Anda dapat menginstal paket dari mana saja (semua sistem kontrol versi, HTTP sewenang-wenang, manajer paket sistem, EmacsWiki, bahkan go get!?). Namun, dengan mendukung begitu banyak sumber, el-get tidak dapat menyediakan jenis operasi manajemen paket canggih (seperti reproduktifitas melalui revisi lockfiles dan operasi manajemen repositori interaktif) yang straight.elmenyediakan. straight.elhanya mendukung Git, karena sebagian besar paket tersedia melalui Git dan yang tidak dapat diperoleh melalui EmacsMirror (Saya berani Anda menemukan satu yang tidak mungkin!). Perhatikan bahwa straight.elbagaimanapun juga menyediakan API yang dapat diperluas untuk backend kontrol versi tambahan (misalnya untuk Mercurial) untuk ditambahkan di masa depan, jika diinginkan.
Borg memiliki filosofi yang sangat mirip straight.eldan memberikan banyak keuntungan yang sama. Namun, tidak dirancang untuk menjadi manajer paket lengkap, dan dirancang untuk digunakan dalam keprihatinan dengan alat-alat lain seperti epkg, auto-compile, dan Magit. Sebaliknya, straight.elmandiri dan menyediakan semua yang Anda butuhkan dengan sendirinya, membutuhkan sedikit atau tanpa konfigurasi tambahan. Juga, Borg menggunakan submitula Git, yang antarmuka-nya memiliki beberapa tepi kasar, sedangkan straight.elmenggunakan repositori Git yang dikelola secara independen, menghasilkan fleksibilitas dan daya tambahan.
Ada juga pendekatan manual, tetapi saya tidak merekomendasikan ini. Setelah beberapa bulan pertama, Anda akan menemukan kembali Borg. Kemudian setelah beberapa bulan ke depan, Anda akan menemukan kembali straight.el. Anda akan belajar banyak tentang manajemen paket;)

— Radon Rosborough
sumber

4

Meskipun ada pro dan kontra, saya pikir el-get masih relevan, meskipun ada pendapat kuat @lunaryon (rejeep juga).

Saya menggunakan paket raw.el dengan use-package untuk sementara waktu (2 sampai 3 tahun), kemudian beralih ke el-get , lalu Cask . Saya kembali ke el-get beberapa hari yang lalu. Package.el sebelumnya , seperti banyak yang lain, saya secara manual menangani add-on.

Mengapa saya kembali ke el-get ? Saya menemukan beberapa keanehan Tong tentang sesuatu yang tidak menjadi git repo (paket Github saya yang tidak di MELPA), sedangkan paket itu sebenarnya menggunakan git ... Saya tidak repot-repot menyelidiki atau membuat tiket, hanya menarik yang lama el-get config dan aku baik-baik saja untuk pergi dalam waktu singkat.

Beberapa hal yang saya sukai dari el-get :

Ini mendukung banyak pengambilan, bukan hanya git.
Ini berisi cukup resep yang sudah ditentukan sebelumnya
Lebih cepat dari Tong saat startup.
dan ya @unaryorn, Wiki bukanlah tempat untuk mendistribusikan kode, tetap saya tidak ingin membuat repo Github jika tidak ada klon pada emacsmirror (Github).
Mandiri, dengan Tong Anda memerlukan instalasi eksternal. Saya menggunakan satu file init (bukan konfigurasi modular) dengan mode allout untuk menavigasi bagian.
el-get cukup sederhana dari perspektif pengguna.

Catatan: Saya menjalankan Emacs Git HEAD di bawah OSX dan Linux.

— rimero
sumber

Saya minta maaf Anda memiliki masalah dengan Cask, tetapi saya tidak berpikir bahwa masalah pribadi Anda dan frustrasi Anda dengan Cask menunjukkan relevansi dengan pertanyaan ini. Secara khusus, Tong adalah ujung ke ELPA dengan cakupan yang sangat sempit (terutama pengembangan paket). Meskipun Anda dapat menggunakannya untuk manajemen paket, juga, secara konsep, ortogonal dapat digunakan.

— lunaryorn

Dengan kata lain, Cask tidak menggantikan el-get, juga tidak bertujuan untuk melakukannya. Sama sekali tidak berhubungan. ELPA menggantikan el-get. Pilihan terbaik untuk instalasi berbasis Git tidak bisa didapatkan lagi, ini adalah QUELPA, dan seperti yang saya katakan dalam jawaban saya, itu adalah alasan yang sah untuk menggunakan QUELPA.

— lunaryorn

1

Saya setuju tentang lingkup sempit Cask, jangan salah paham. Meskipun "masalah" saya dengan Cask, saya masih menggunakannya di beberapa mesin Linux. Saya juga tidak memiliki paket "git-only", beberapa di antaranya berada dalam sistem kontrol versi lincah atau lainnya. Saya juga menggunakan paket dari orang lain yang kemungkinan besar tidak akan pernah berada di MELPA atau repositori git. Satu-satunya poin saya adalah bahwa el-get masih ok ketika MELPA tidak berisi semua paket yang dibutuhkan oleh seseorang. Sementara saya menyadari QUELPA, el-get cukup baik untuk saya.

— rimero

Lihat, dan maksud saya adalah bahwa el-get secara khusus sudah tidak bagus lagi saat ini, karena memintas manajemen ketergantungan ELPA dan bawaan Emacs, mempertaruhkan kerusakan dan menduplikasi instalasi paket. QUELPA menyediakan fitur yang sama dengan el-get, tetapi tidak memiliki kekurangan ini. Hanya saja lebih baik saat ini.

— lunaryorn

@rimero Saya memiliki pengalaman yang sama persis. Selain itu, saya baru saja mencoba Quelpa beberapa hari yang lalu, dan harus menjatuhkannya, setidaknya untuk saat ini. El-get tampaknya masih lebih fleksibel, kuat, dan secara keseluruhan lebih cepat, setidaknya untuk kasus penggunaan saya. Saya percaya mereka merangkul dua perspektif yang sangat berbeda, jadi itu mungkin juga tergantung pada jenis pengguna Emacs apa. Dianjurkan untuk mencoba keduanya, sebelum melakukan satu atau yang lain.

— gsl

1

Anda mungkin ingin melihatnya paradox. Ini bukan manajer paket lain, tetapi ujung depan yang lebih rapi untuk package.el. Misalnya, ketika Anda memperbarui paket, ia bertanya apakah Anda ingin menginstalnya dan menghapus yang lama dalam satu langkah.

Jika Anda menggunakannya, Anda mungkin ingin mengatur paradox-execute-asynchronouslyke tdalam file init Anda.

— Pascal
sumber

Apa kasus penggunaan manajer paket alternatif vis-à-vis `package.el`?

Latar Belakang

Pertanyaan