Sự khác biệt thực tế giữa các kho gói Emacs khác nhau là gì?


124

Tôi nhận thấy rằng có một số kho lưu trữ khác nhau thường chứa cùng một phần mềm. Tại sao tôi muốn thích:

  • GNU ELPA
  • Marmalade
  • MELPA

hơn những người khác? Vì bất kỳ một kho lưu trữ nào không chứa tất cả các gói mà tôi muốn, có nên cho phép các kho lưu trữ này được kích hoạt đồng thời không?

Câu trả lời:


82

GNU ELPA là kho lưu trữ gói GNU Emacs chính thức. Đây là cái duy nhất được bật theo mặc định, có nghĩa là nó có phạm vi tiếp cận lớn nhất. Đồng thời, việc gửi một gói có một chút rắc rối và yêu cầu chuyển nhượng bản quyền của FSF, có nghĩa là nó có một lựa chọn các gói tương đối hạn chế.

MELPAMarmalade đều là kho lưu trữ của bên thứ ba. Chúng không được GNU hỗ trợ chính thức, nhưng cũng có các lựa chọn gói lớn hơn nhiều. Chất lượng gói có nhiều thay đổi hơn một chút, nhưng bạn có nhiều khả năng tìm thấy bất cứ thứ gì bạn đang tìm kiếm, đặc biệt là nếu nó hơi tối nghĩa.

Marmalade và MELPA có các mô hình hơi khác nhau cho các trình tải lên gói. Tôi hiểu rằng MELPA theo dõi một kho lưu trữ kiểm soát phiên bản trực tiếp (tức là thông qua GitHub), cho phép các tác giả gói cập nhật các gói chỉ bằng cách đẩy các cam kết vào một nhánh. Marmalade, mặt khác, có người tải các gói lên kho lưu trữ một cách rõ ràng.

Trong thực tế, tôi chưa thấy nhiều sự khác biệt giữa MELPA và Marmalade. Không có nhiều nhược điểm để cho phép cả hai có lựa chọn gói có thể cài đặt lớn nhất có thể: Tôi đã sử dụng cả hai (và GNU ELPA, tất nhiên) trong một thời gian mà không gặp vấn đề gì đáng kể.

Một mối quan tâm có thể có (mà tôi không gặp phải với bản thân mình) khi bật cả hai kho lưu trữ, mà tôi không chạy vào chính mình, là có các gói có sẵn từ cả hai phiên bản khác nhau. Theo mặc định, trình quản lý gói ( package.el) không có cách nào để giải quyết xung đột như thế này; tuy nhiên, bạn có thể giải quyết vấn đề này bằng cách cài đặt melpagói cho phép bạn tùy chỉnh gói nào được cung cấp hoặc loại trừ khỏi kho lưu trữ nào. Bạn có thể xem thêm chi tiết tại đây hoặc từ tài liệu cho melpagói.

Như @Malabarba đã chỉ ra một cách hữu ích, vấn đề này được giải quyết trong Emacs 24.4.

Nếu bạn thực sự lo lắng về bảo mật, bạn có thể muốn tránh cả MELPA và Marmalade vì họ cho phép bất kỳ ai tải lên các gói và, theo như tôi biết, không có bất kỳ thỏa thuận bảo mật chủ động nào. Mặt khác, kho lưu trữ GNU ELPA được quản lý bởi FSF và đã ký các gói cần trợ giúp. Tất nhiên, nếu bảo mật thực sự quan trọng, bạn có thể muốn xem xét và cài đặt các gói elisp bằng tay thay vì sử dụng trình quản lý gói.


13
Gói.el mới đi kèm trong emacs 24.4 xử lý số phiên bản chuyển hướng một cách duyên dáng. Nếu hai repos có cùng gói với phiên bản khác nhau, bạn sẽ được cung cấp cả hai và một sẽ không bao giờ ghi đè lên gói kia trong khi cập nhật.
Malabarba

1
@Malabarba: Wow, thật tuyệt khi nghe!
Tikhon Jelvis

14
Đây là một câu trả lời tốt nhưng có lẽ cũng nên đề cập đến MELPA ổn định ( melpa-urdy.milkbox.net ). MELPA sẽ tự động nhận bản sửa đổi mới nhất từ ​​chi nhánh chính của repo, trong khi MELPA ổn định sẽ có bản sửa đổi được gắn thẻ mới nhất.
shosti

@shosti: Ồ, gọn gàng, tôi không biết về điều đó. Thật sự có thể tốt khi đặt nó như là câu trả lời của chính nó.
Tikhon Jelvis

7
marmalade không cho phép bất cứ ai tải lên các gói. chỉ người dùng đã đăng ký. Tôi biết tất cả các người tải lên ngay bây giờ. Vì vậy, có một số loại đánh giá ngang hàng.
nic ferrier

44

Theo cách tôi nghĩ về nó, một số repos có nhiều chi phí liên quan đến việc gửi các gói hơn những cái khác; các repos có nhiều chi phí hơn có xu hướng có ít gói hơn. Theo thứ tự từ hầu hết đến ít nhất:

  1. GNU ELPA yêu cầu tất cả các mã phải là GPL và bản quyền được gán cho FSF. Mã ELPA về cơ bản được "sở hữu" bởi nhóm Emacs cốt lõi, do đó, nó ít hơn nhiều so với các repos khác. (chế độ org có repo riêng, nhưng nó có cùng chế độ hoạt động.)
  2. Marmalade yêu cầu tất cả các mã phải có giấy phép tương thích GPL và tất cả các gói được tải lên theo cách thủ công. Quyền sở hữu là một chút không xác định và việc thay đổi quyền sở hữu không có quy trình AFAIK được thiết lập.
  3. MELPA Stable ít nhiều cạnh tranh trực tiếp với Marmalade, ngoại trừ nó không có hạn chế về giấy phép và tự động xây dựng các gói từ git repos bằng bản sửa đổi được gắn thẻ mới nhất. Quyền sở hữu được xác định thông qua repo MELPA (thay đổi quyền sở hữu xảy ra thông qua yêu cầu kéo).
  4. MELPA giống như MELPA ổn định ngoại trừ nó luôn lấy từ bản sửa đổi mới nhất trên nhánh chính của một repo git. Các gói có xu hướng "chảy máu", và nó có thể là một chút của sự ổn định miễn phí cho tất cả sự ổn định (có ưu và nhược điểm).

Cá nhân tôi nghĩ rằng MELPA Stable hoặc Marmalade có thể sẽ chiến thắng trong thời gian dài đối với hầu hết người dùng. MELPA thích hợp là không ổn định và ELPA quá hạn chế để có thể mở rộng cho nhiều gói. Nhưng đó chỉ là một ý kiến.


6
marmalade hiện có API để thêm chủ sở hữu vào các gói.
nic ferrier

31

Có một số kho gói có sẵn.

Chính thức

GNU ELPA là repo gói chính thức. Nó nhỏ và yêu cầu chuyển nhượng bản quyền (của tất cả các tác giả của một gói) cho FSF để đóng góp cho nó.

Các gói trên GNU ELPA thực sự chỉ là một repo git . Ưu điểm của việc được lưu trữ ở đây là nhóm nòng cốt cố gắng cập nhật các gói nếu chính Emacs thêm hoặc không dùng các tính năng.

Được xây dựng từ nguồn

MELPA là repo gói lớn nhất và phát triển nhanh nhất . Nó phát hành một phiên bản mới mỗi khi một phiên bản mới được đẩy lên repo hoặc trang EmacsWiki được cập nhật.

Đó là chảy máu cạnh, nhưng nó hoạt động rất tốt trong thực tế. MELPA được quản lý để tránh các gói trùng lặp và để đảm bảo rằng gói chính thức được ghi lại (thay vì một ngã ba ngẫu nhiên).

MELPA có vấn đề là các phiên bản chỉ là dấu thời gian, vd my-package-20131231.2359. Điều này có nghĩa là nếu bạn phụ thuộc vào gói của tôi:

;; Package-Requires: ((my-package "1.2.3"))

sau đó Emacs sẽ nghĩ rằng bất kỳ phiên bản nào trên MELPA đều đủ mới.

MELPA Stable giống như MELPA, nhưng thay vì sử dụng các phiên bản dấu thời gian, nó sử dụng các phiên bản trong thẻ git. Điều này cho phép giải quyết phụ thuộc tốt hơn, nhưng có vấn đề tùy thuộc vào các gói wiki .

Người dùng tải lên

Marmalade giống như một kho lưu trữ truyền thống từ các ngôn ngữ lập trình khác. Nhà phát triển gói tải gói lên Marmalade khi họ phát hành.

Về nguyên tắc, điều này mang lại cho các gói một quy trình phát hành phù hợp (Marmalade có trước MELPA ổn định) và cũng tránh được vấn đề về số phiên bản tự phát. Tuy nhiên, không có xác minh danh tính. Bất cứ ai cũng có thể tải lên một gói, ngay cả khi họ không viết nó. Điều này trở nên khó khăn nếu người duy trì my-packagephát hiện ra rằng người khác đã tải lên my-packagevà sau đó không thể tải lên các phiên bản mới.

Marmalade từng là một ứng dụng node.js và giờ đây nó được viết bằng elisp. Cả hai phiên bản thỉnh thoảng có vấn đề về thời gian hoạt động.

Dự án cụ thể

ELPA chế độ Org là một repo chỉ lưu trữ orgorg-plus-contrib. Chế độ Org là một phần của lõi Emacs, nhưng nó được phát triển bên ngoài và mã chỉ được đồng bộ hóa với thân Emacs theo định kỳ. Repo này cho phép bạn có chế độ org cạnh chảy máu.

User42 ELPA là một repo cho một nhà phát triển gói duy nhất đã phát hành khá nhiều gói Emacs . Nếu bạn thích bất kỳ gói nào của anh ấy, bạn có thể thêm repo này.

Sunrise Commander ELPA là một repo cho các phần mở rộng cho Sunrise Commander (gói Emacs để duyệt tệp, lấy cảm hứng từ chỉ huy nửa đêm).

Nghỉ hưu

ELPA của Tromey là repo đầu tiên được thiết lập. Nó chính thức được thay thế bằng GNU ELPA, nhưng nó không có cùng yêu cầu chuyển nhượng bản quyền. Kể từ năm 2010, nó không còn được cập nhật.

Kho lưu trữ gói Elpy chứa các gói khác nhau được phát triển bởi Jorgen Schaefer cho 'Elpy, Môi trường phát triển Python của Emacs' , nhưng đã được chuyển sang MELPA Stable.


4
marmalade chắc chắn đã có vấn đề về thời gian hoạt động ... Tôi tin rằng tôi đã giải quyết chúng bằng nic.ferrier.me.uk/blog/2014_08/deploying-blue-green-with-docker - không ai đề cập đến những rủi ro khi sử dụng github , một nhà cung cấp thương mại phần mềm dựa trên web, như một phụ trợ; Tôi tin rằng đó là một rủi ro. Marmalade là phần mềm miễn phí và ngay cả những thứ được xây dựng cũng có thể cài đặt được bởi người khác.
nic ferrier

no one has mentioned the risks involved in using github, a commercial provider of web based software, as a backend: nhưng tôi chắc chắn rằng những lo ngại đó sẽ biến mất ngay bây giờ khi đó là Microsoft GitHub ;-)
TomRoche

13

Một số thông tin bổ sung, để bổ sung các câu trả lời khác ở đây.

  1. Một số thông tin về MELPA và MELPA "ổn định" -

    Bắt đầu bằng cách xem xét câu hỏi trùng lặp khá nhiều này , từ StackOverflow, bao gồm cả các nhận xét cho chính câu hỏi. Đặc biệt, bình luận này mà tôi đã đăng, sau khi trao đổi email với Donald Curtis (người duy trì MELPA và MELPA ổn định):

    Từ quan điểm của anh ấy [Donald Curtis, và như tôi hiểu giao tiếp của anh ấy với tôi], trang MELPA "ổn định" chỉ ở chế độ bảo trì . Và lý do duy nhất mà mã như của tôi không có là không có ai thực hiện tải lên từ wiki [Emacs Wiki] cho trang web "ổn định". Ngoài ra, không có ai "quản lý" được thực hiện bởi bất kỳ ai - không lọc để xác định xem gói có ổn định, có rủi ro hay không. Sự tồn tại của hai trang web được yêu cầu bởi một số nhà phát triển gói muốn phân biệt các phiên bản dev của gói với cũ hơn ("ổn định" ") phiên bản.

    Tóm lại, không có gì vốn dĩ "ổn định" hơn về nội dung trên "MELPA ổn định" . Cách đánh số phiên bản và phương thức nạp có thể khác nhau; đó là tất cả. Và nếu một nhà bảo trì gói cụ thể muốn phân biệt các phiên bản "ổn định" với các phiên bản "phát triển" và muốn làm điều đó bằng cách tải chúng lên hai trang web khác nhau, thì đó chính là hiệu ứng - cho gói đó .

  2. Một điểm khác biệt giữa MELPA và Marmalade (và GNU ELPA) là không yêu cầu mã đóng góp cho MELPA có nguồn gốc từ kho lưu trữ git. Đặc biệt, nó có thể được tự động kéo từ Elisp Area of ​​Emacs Wiki .

    Điều đó có nghĩa là, như một số người đã nói, rằng bất kỳ ai cũng có thể tải lên bất cứ điều gì, và bạn không có cách nào để biết liệu mã thực sự là của tác giả đã tuyên bố, v.v.? Có và không. Nói chung, có: bất cứ ai cũng có thể tự do tải mã Elisp lên Emacs Wiki. Như đầu trang Elisp-Area nói:

    Đây là khu vực elisp EmacsWiki, nơi chúng tôi thu thập các tệp EmacsLisp. Không cần đăng nhập, không yêu cầu kiểm soát phiên bản, không yêu cầu ftp, không yêu cầu mật khẩu. Nó đơn giản như chính wiki. Điều đó cũng có nghĩa là bất kỳ ai cũng có thể đặt mã độc trong các tệp EmacsLisp này. Nếu nghi ngờ, đừng sử dụng chúng.

    Tuy nhiên, để bạn biết, tôi là quản trị viên của wiki và các thư viện Lisp của riêng tôi trong Khu vực Elisp wiki là các trang bị khóa. Điều đó có nghĩa là chỉ có quản trị viên wiki mới có thể tải chúng lên. Vì vậy, trong trường hợp này, bạn có thể khá chắc chắn rằng các thư viện của tôi mà bạn tải xuống từ MELPA hoặc Emacs Wiki đã được tôi tải lên. Tuy nhiên, như với mọi thứ trên Internet, không có bảo đảm bằng sắt, giống như không có bảo đảm với chính mã. Như GPL blurb trong mọi thư viện GPL nói:

    Chương trình này được phân phối với hy vọng nó sẽ hữu ích, nhưng KHÔNG CÓ BẤT K WAR ĐẢM BẢO NÀO; thậm chí không có sự bảo đảm ngụ ý của MERCHANTABILITY hoặc FITNESS CHO MỘT MỤC ĐÍCH THAM GIA. Xem Giấy phép Công cộng GNU để biết thêm chi tiết.

HTH. Chúc mừng hack.


Tôi rất yên tâm.
nic ferrier

1
Hãy để tôi không đồng ý với ý kiến ​​MELPA của bạn. Gói tác giả không „phát hành bất cứ điều gì cho MELPA. Anh ấy hoặc cô ấy chỉ cam kết với repo của riêng mình, và MELPA chọn nó. Sự khác biệt là MELPA chọn bất cứ thứ gì, trong khi MELPA chọn ổn định các bản phát hành được gắn thẻ . Đây thực tế là một vấn đề ưu tiên. Một số người thích luôn tạo ra nhánh tính năng, coi thân cây là thiêng liêng và báo hiệu rằng sự thay đổi đã sẵn sàng bằng cách hợp nhất với thân cây. Những người khác tình cờ phát triển trên thân cây nhưng đánh dấu các bản phát hành sẵn sàng bằng cách gắn thẻ rõ ràng. Cả hai cách tiếp cận đều hợp lý
Mekk

1
Tôi đang ở bên gắn thẻ vì nó cho tôi biết ngay khi nào và tại sao tôi phát hành (và cho phép xuất bản các phiên bản sơ bộ trên thân cây, và tránh sự cần thiết phải tạo các nhánh tính năng để thay đổi mã nhỏ và cho phép tôi sử dụng số phiên bản để báo hiệu mức độ thay đổi lớn như thế nào và cho phép tôi sử dụng số phiên bản thân thiện với con người). Điểm mấu chốt: miễn là có các tác giả thích gắn thẻ phát hành, melpa ổn định có giá trị - và tôi nói không có gì sai trong tác giả quản lý các bản phát hành bằng cách gắn thẻ, ngược lại, điều đó có nghĩa là anh ta hoặc cô ta quan tâm nghĩ khi nào và nên làm gì được phát hành
Mekk
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.