Emacs Package Repositories แตกต่างกันอย่างไร

ฉันสังเกตเห็นว่ามีที่เก็บหลายแห่งที่มักจะมีซอฟต์แวร์เดียวกัน ทำไมฉันต้องการที่จะชอบ:

• GNU ELPA
• แยมผิวส้ม
• MELPA

มากกว่าคนอื่น ๆ ? เนื่องจากที่เก็บหนึ่งแห่งไม่มีแพ็คเกจทั้งหมดที่ฉันต้องการมันเป็นความคิดที่ดีหรือไม่ที่เปิดใช้ที่เก็บเหล่านี้พร้อมกัน?

GNU ELPAเป็นที่เก็บแพคเกจ GNU Emacs อย่างเป็นทางการ มันเป็นสิ่งเดียวที่เปิดใช้งานโดยค่าเริ่มต้นซึ่งหมายความว่ามันเข้าถึงได้มากที่สุด ในเวลาเดียวกันการส่งแพคเกจมีความยุ่งยากและต้องมีการมอบหมายลิขสิทธิ์ FSF ซึ่งหมายความว่ามีการเลือกแพคเกจค่อนข้าง จำกัด

MELPAและMarmaladeเป็นที่เก็บแพ็กเกจของบุคคลที่สาม GNU ไม่ได้รับการสนับสนุนอย่างเป็นทางการ แต่ยังมีแพ็คเกจให้เลือกมากมาย คุณภาพของแพ็คเกจเป็นตัวแปรมากกว่า แต่คุณก็มีแนวโน้มที่จะพบสิ่งที่คุณกำลังมองหาโดยเฉพาะอย่างยิ่งถ้ามันค่อนข้างคลุมเครือ

Marmalade และ MELPA มีรูปแบบที่แตกต่างกันเล็กน้อยสำหรับผู้อัปโหลดแพ็คเกจ ความเข้าใจของฉันคือ MELPA ติดตามที่เก็บข้อมูลการควบคุมเวอร์ชันโดยตรง (เช่นผ่าน GitHub) เพื่อให้ผู้เขียนแพ็คเกจอัปเดตแพ็คเกจเพียงแค่กดคอมมิชชันที่สาขา ในทางกลับกันมาร์มาเลดก็มีคนอัพโหลดแพ็คเกจไปยังที่เก็บอย่างชัดเจน

ในทางปฏิบัติฉันไม่เห็นความแตกต่างระหว่าง MELPA และ Marmalade มาก มีข้อเสียไม่มากที่ทำให้ทั้งคู่มีตัวเลือกที่ใหญ่ที่สุดที่เป็นไปได้ของแพ็คเกจที่ติดตั้งได้: ฉันใช้ทั้ง (และ GNU ELPA แน่นอน) มาพักหนึ่งแล้วโดยไม่มีปัญหาที่สำคัญ

สิ่งหนึ่งที่เป็นไปได้เกี่ยวกับความกังวล (ซึ่งฉันไม่ได้พบเจอตัวเอง) เมื่อเปิดใช้ที่เก็บข้อมูลทั้งคู่ซึ่งฉันไม่ได้พบเจอเองก็คือการมีแพ็คเกจพร้อมใช้งานจากทั้งสองเวอร์ชัน ตามค่าเริ่มต้นตัวจัดการแพ็กเกจ ( package.el) จะไม่มีวิธีแก้ไขข้อขัดแย้งเช่นนี้ อย่างไรก็ตามคุณสามารถแก้ไขปัญหานี้ได้โดยการติดตั้งmelpaแพคเกจที่ให้คุณปรับแต่งแพ็คเกจที่ให้หรือแยกออกจากที่เก็บ คุณสามารถดูรายละเอียดเพิ่มเติมได้ที่นี่หรือจากเอกสารประกอบของmelpaแพ็คเกจ

เนื่องจาก @Malabarba ชี้ให้เห็นอย่างเป็นประโยชน์ปัญหานี้ได้รับการแก้ไขใน Emacs 24.4

หากคุณกังวลเกี่ยวกับความปลอดภัยคุณอาจต้องการหลีกเลี่ยงทั้ง MELPA และ Marmalade เพราะพวกเขาให้ทุกคนอัปโหลดแพ็คเกจและเท่าที่ฉันรู้ไม่มีการจัดการด้านความปลอดภัยเชิงรุก ในทางกลับกันที่เก็บ GNU ELPA ได้รับการจัดการโดย FSF และได้ลงนามในแพ็คเกจที่น่าจะช่วยได้ แน่นอนถ้าการรักษาความปลอดภัยมีความสำคัญจริง ๆ คุณอาจต้องการตรวจสอบและติดตั้งแพคเกจ elisp ด้วยมือแทนการใช้ตัวจัดการแพคเกจ

อย่างที่ฉันคิดไว้ repos บางคนมีค่าใช้จ่ายที่เกี่ยวข้องกับการส่งแพ็คเกจมากกว่าคนอื่น repos ที่มีค่าใช้จ่ายมากกว่ามักจะมีแพ็คเกจน้อยกว่า ตามลำดับจากค่าใช้จ่ายมากไปน้อย

1. GNU ELPAต้องการรหัสทั้งหมดเพื่อเป็น GPL และลิขสิทธิ์ที่กำหนดให้กับ FSF รหัส ELPA นั้นโดยหลักแล้ว "เป็นเจ้าของ" โดยทีมงานหลักของ Emacs ดังนั้นจึงมีน้อยกว่ารหัส repos อื่น ๆ (โหมด org มี repo ของตัวเอง แต่มันมีโหมดการทำงานเหมือนกัน)
2. Marmaladeต้องการรหัสทั้งหมดเพื่อให้มีใบอนุญาตที่เข้ากันได้กับ GPL และอัปโหลดแพ็คเกจทั้งหมดด้วยตนเอง ความเป็นเจ้าของนั้นไม่มีการระบุเล็กน้อยและการเปลี่ยนความเป็นเจ้าของไม่มีกระบวนการ AFAIK
3. MELPA Stableมีการแข่งขันโดยตรงกับ Marmalade มากหรือน้อยยกเว้นว่าจะไม่มีข้อ จำกัด สิทธิ์การใช้งานและสร้างแพ็คเกจจาก git repos โดยอัตโนมัติโดยใช้การแก้ไขที่ติดแท็กล่าสุด ความเป็นเจ้าของจะถูกกำหนดผ่านrepo MELPA (การเปลี่ยนแปลงความเป็นเจ้าของเกิดขึ้นผ่านคำขอดึง)
4. MELPAนั้นเหมือน MELPA ที่มีความเสถียรยกเว้นมันจะดึงจากการแก้ไขล่าสุดในสาขาหลักของ repo git แพ็คเกจมีแนวโน้มที่จะ "ตกเลือด" และมันอาจจะเป็นความเสถียรที่ชาญฉลาด (ซึ่งมีข้อดีและข้อเสีย)

โดยส่วนตัวแล้วฉันคิดว่า MELPA Stable หรือ Marmalade อาจชนะในระยะยาวสำหรับผู้ใช้ส่วนใหญ่ - MELPA เหมาะสมค่อนข้างไม่เสถียรและ ELPA นั้นเข้มงวดเกินไปที่จะปรับขนาดได้สำหรับแพ็คเกจจำนวนมาก แต่นั่นเป็นเพียงความเห็น

มีที่เก็บแพคเกจหลายแห่ง

เป็นทางการ

GNU ELPAเป็นแพคเกจซื้อคืนอย่างเป็นทางการ มันมีขนาดเล็กและต้องมีการมอบหมายลิขสิทธิ์ (ของผู้เขียนทั้งหมดของแพ็คเกจ) ให้กับ FSF เพื่อมีส่วนร่วม

แพคเกจใน GNU ELPA จริงๆเพียงrepo คอมไพล์ ข้อดีของการโฮสต์ที่นี่คือทีมหลักพยายามอัปเดตแพ็กเกจหาก Emacs เพิ่มหรือยกเลิกคุณสมบัติ

สร้างขึ้นจากแหล่งที่มา

MELPAเป็นธุรกรรมซื้อแพ็คเกจที่ใหญ่และเติบโตเร็วที่สุด มันออกรุ่นใหม่ทุกครั้งที่มีการผลักรุ่นใหม่ไปยัง repo หรือหน้า EmacsWiki ได้รับการปรับปรุง

ขอบเลือดออก แต่ก็ใช้งานได้ดีในทางปฏิบัติ MELPA ได้รับการดูแลเพื่อหลีกเลี่ยงแพ็กเกจที่ซ้ำกันและเพื่อให้แน่ใจว่ามีการบันทึกที่บ้านมาตรฐานของแพคเกจ (แทนการสุ่มแยก)

MELPA จะมีปัญหาที่รุ่นเป็นเพียง timestamps my-package-20131231.2359เช่น ซึ่งหมายความว่าถ้าคุณขึ้นอยู่กับแพ็คเกจของฉัน:

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

จากนั้น Emacs จะคิดว่า MELPA รุ่นใดก็ตามนั้นใหม่พอ

MELPA Stableนั้นเหมือนกับ MELPA แต่แทนที่จะใช้รุ่น datestamp จะใช้รุ่นในแท็ก git นี้จะช่วยให้ความละเอียดของการพึ่งพาที่ดีขึ้น แต่มีปัญหาเกี่ยวกับการขึ้นอยู่กับแพคเกจที่วิกิพีเดีย

ผู้ใช้อัปโหลด

Marmaladeเป็นเหมือนที่เก็บแบบดั้งเดิมจากภาษาโปรแกรมอื่น ๆ ผู้พัฒนาแพ็คเกจอัพโหลดแพ็คเกจไปที่ Marmalade เมื่อพวกเขาเปิดตัว

โดยหลักการแล้วสิ่งนี้จะช่วยให้กระบวนการปล่อยแพคเกจที่เหมาะสม (Marmalade ถือกำเนิด MELPA ที่เสถียร) และหลีกเลี่ยงปัญหาหมายเลขรุ่นที่สร้างอัตโนมัติ อย่างไรก็ตามไม่มีการยืนยันตัวตน ทุกคนสามารถอัปโหลดแพ็คเกจได้แม้ว่าจะไม่ได้เขียนก็ตาม สิ่งนี้จะยากหากผู้ดูแลของmy-packageพบว่ามีคนอื่นอัปโหลดmy-packageและไม่สามารถอัปโหลดเวอร์ชันใหม่ได้ในภายหลัง

Marmalade เคยเป็นแอพ node.js และตอนนี้มันเขียนด้วย elisp ทั้งสองเวอร์ชันมีปัญหาสถานะการออนไลน์เป็นครั้งคราว

โครงการเฉพาะ

org โหมด ELPAเป็น repo ที่เพียงเจ้าภาพและorg org-plus-contribOrg-mode เป็นส่วนหนึ่งของ Core ของ Emacs แต่ได้รับการพัฒนาจากภายนอกและรหัสจะถูกซิงค์กับ Emacs trunk เป็นระยะเท่านั้น repo นี้ช่วยให้คุณมีโหมด org-edge

User42 ELPAเป็น repo สำหรับผู้พัฒนาแพ็คเกจรายเดียวซึ่งได้เปิดตัวแพ็คเกจ Emacs จำนวนมาก ถ้าคุณชอบแพ็คเกจใด ๆ ของเขาคุณสามารถเพิ่ม repo นี้ได้

Sunrise Commander ELPAเป็น repo สำหรับส่วนขยายสำหรับSunrise Commander (แพ็คเกจ Emacs สำหรับการเรียกดูไฟล์ที่ได้รับแรงบันดาลใจจากผู้บัญชาการเที่ยงคืน)

ถอยออก

ELPA ของ Tromeyเป็นธุรกรรมซื้อคืนแรก มันถูกแทนที่อย่างเป็นทางการด้วย GNU ELPA แต่ไม่มีข้อกำหนดการโอนลิขสิทธิ์เหมือนกัน ตั้งแต่ปี 2010 ไม่มีการปรับปรุงอีกต่อไป

ไฟล์เก็บถาวรของแพคเกจ Elpyมีแพ็คเกจต่าง ๆ ที่พัฒนาโดย Jorgen Schaefer สำหรับ'Elpy, Emacs Python Development Environment'แต่ได้ย้ายไปยัง MELPA Stable แล้ว

ข้อมูลเพิ่มเติมเพื่อเสริมคำตอบอื่น ๆ ที่นี่

1. ข้อมูลบางอย่างเกี่ยวกับ MELPA และ MELPA "เสถียร" -

   เริ่มต้นด้วยการดูคำถามที่ซ้ำกันสวย ๆ นี้จาก StackOverflow รวมถึงความคิดเห็นสำหรับคำถามนั้น โดยเฉพาะอย่างยิ่งความคิดเห็นนี้ที่ฉันโพสต์หลังจากแลกเปลี่ยนอีเมลกับ Donald Curtis (ผู้ดูแล MELPA และ MELPA เสถียร):

   จากมุมมองของเขา [โดนัลด์เคอร์ติและที่ผมเข้าใจการสื่อสารของเขากับผม] ว่า "คงที่" เว็บไซต์ MELPA อยู่ในโหมดการบำรุงรักษาเท่านั้น และเหตุผลเดียวที่รหัสเช่นของฉันไม่มีนั้นไม่มีใครทำการอัปโหลดจาก wiki [Emacs Wiki] สำหรับเว็บไซต์ "เสถียร" นอกจากนี้ยังไม่มี "curating" ที่ทำโดยใคร - ไม่มีการกรองเพื่อตรวจสอบว่าแพคเกจมีความเสถียรมีความเสี่ยง ฯลฯ มีการร้องขอเว็บไซต์สองแห่งโดยนักพัฒนาแพคเกจบางคนที่ต้องการแยกแพคเกจรุ่น dev ของพวกเขาออกจากรุ่นเก่า ") เวอร์ชัน

   สรุปแล้วไม่มีอะไรที่ "เสถียร" เกี่ยวกับเนื้อหาใน "MELPA เสถียร" ที่มากกว่าโดยทั่วไป หมายเลขรุ่นและวิธีการฟีดอาจแตกต่างกัน นั่นคือทั้งหมดที่ และหากผู้ดูแลแพคเกจเฉพาะต้องการแยกรุ่น "เสถียร" จาก "การพัฒนา" และต้องการทำเช่นนั้นโดยการอัปโหลดไปยังสองไซต์ที่ต่างกันนั่นคือผลกระทบ - สำหรับแพ็คเกจนั้น

2. ความแตกต่างอย่างหนึ่งระหว่าง MELPA และ Marmalade (และ GNU ELPA) คือไม่จำเป็นว่ารหัสที่สนับสนุน MELPA นั้นมาจากแหล่งเก็บข้อมูลคอมไพล์ โดยเฉพาะอย่างยิ่งจะถูกดึงโดยอัตโนมัติจากพื้นที่ Elisp ของ Emacs วิกิพีเดีย

   นั่นหมายความว่าอย่างที่บางคนบอกว่าทุกคนสามารถอัปโหลดอะไรก็ได้และคุณไม่มีทางรู้ว่ารหัสนั้นเป็นของผู้เขียนที่อ้างสิทธิ์จริง ๆ หรือไม่? ใช่และไม่. โดยทั่วไปใช่: ทุกคนสามารถอัปโหลดโค้ด Elisp ไปยัง Emacs Wiki ได้ ตามที่ด้านบนของหน้า Elisp-Area บอกว่า:

   นี่คือพื้นที่ Elac EmacsWiki ที่เรารวบรวมไฟล์ EmacsLisp ไม่จำเป็นต้องเข้าสู่ระบบไม่จำเป็นต้องควบคุมเวอร์ชันไม่จำเป็นต้องใช้ ftp ไม่ต้องใช้รหัสผ่าน มันง่ายเหมือนวิกิเอง นั่นหมายความว่าทุกคนสามารถวางโค้ดที่เป็นอันตรายในไฟล์ EmacsLisp เหล่านี้ได้ หากมีข้อสงสัยอย่าใช้มัน

   อย่างไรก็ตามเพื่อให้คุณรู้ว่าฉันเป็นผู้ดูแลของวิกิและห้องสมุดเสียงกระเพื่อมของฉันเองในวิกิพีเดีย Elisp เป็นหน้าล็อค นั่นหมายความว่าเฉพาะผู้ดูแลวิกิเท่านั้นที่สามารถอัปโหลดได้ ดังนั้นในกรณีนี้คุณมั่นใจได้เลยว่าไลบรารี่ของฉันที่คุณดาวน์โหลดจาก MELPA หรือ Emacs Wiki นั้นอัปโหลดโดยฉัน อย่างไรก็ตามเช่นเดียวกับทุกสิ่งบนอินเทอร์เน็ตไม่มีการรับประกันว่าไม่มีเกราะหุ้มเกราะเช่นเดียวกับที่ไม่มีการรับประกันด้วยรหัสเอง ตามที่ GPL ประกาศแจ้งในห้องสมุด GPL ทุกคนพูดว่า:

   โปรแกรมนี้เผยแพร่ด้วยความหวังว่าจะเป็นประโยชน์ แต่ไม่มีการรับประกันใด ๆ โดยไม่ต้องมีการรับประกันโดยนัยของความสามารถในการซื้อขายหรือความเหมาะสมสำหรับวัตถุประสงค์เฉพาะ ดูใบอนุญาตสาธารณะทั่วไปของ GNU สำหรับรายละเอียดเพิ่มเติม

HTH แฮ็คมีความสุข