พื้นหลัง

ฉันใช้ emacs ทุกวัน แต่ส่วนใหญ่จะทำสิ่งต่าง ๆ ให้เสร็จ ฉันไม่ชอบการปรับแต่งมากกว่าการเพิ่มแพ็คเกจและฉันไม่ชอบการแก้ไขปัญหา ฉันต้องการ emacs ที่จะจางหายไปในพื้นหลังอย่างที่ระบบปฏิบัติการที่ดีทำได้ ไม่นานมานี้ฉันพบว่า el-getอนุญาตให้ฉันติดตั้งแพคเกจที่ฉันต้องการซึ่งไม่สามารถใช้งานได้package.elและยังให้ฉันควบคุมได้มากขึ้นเช่นการเลือกmaintสาขาของโหมด Org-mode แทนที่จะเป็นขอบเลือดออกซึ่งอาจทำให้เกิดปัญหาชั่วคราว ตอนนี้ฉันไม่แน่ใจว่าควรใช้el-getหรือไม่

คำถาม

el-getดูเหมือนจะเป็นทางออกที่ดีสำหรับคลังเก็บต่างๆและ emacs แฮ็คออกมี package.elมันนำเสนอความสามารถที่มีเพียงแค่ไม่ได้กับ ตอนนี้package.elใน emacs รุ่นใหม่กว่า ( >=24.4) รองรับที่เก็บข้อมูลหลายแห่งสิ่งที่เป็นกรณีการใช้งานel-getและทางเลือกที่คล้ายคลึงกับตัวจัดการแพคเกจในตัวของ emacs?

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

ฉันคิดว่าแม้ว่า el-get นั้นเป็นโซลูชันแบบดั้งเดิมในปัจจุบัน เนื่องจาก ELPA ได้กลายเป็นผู้จัดการแพคเกจมาตรฐานแบบเสมือนจริงสำหรับ Emacs ผู้จัดการแพคเกจอื่นควรรวมเข้ากับ ELPA ได้อย่างลงตัว อย่างไรก็ตาม el-get ไม่ได้เปิดเผยแพ็คเกจของตัวเองไปยัง ELPA ซึ่งหมายความว่าแพ็กเกจนั้นไม่สามารถมองเห็นได้โดยสิ้นเชิงกับแพ็คเกจ ELPA และ ELPA ไม่สามารถพึ่งพาแพ็คเกจ el-get ได้โดยมีนัยสำคัญสำหรับการจัดการการพึ่งพา

หากคุณต้องการคุณสมบัติที่เหนือกว่า ELPA คุณควรดู QUELPA แทนที่จะเป็น el-get

ฉันได้เขียนผู้จัดการแพ็คเกจใหม่สำหรับ Emacs straight.elซึ่งพยายามปรับปรุงโซลูชันการจัดการบรรจุภัณฑ์ที่มีอยู่ทั้งหมด มีส่วนที่ครอบคลุมในstraight.elเอกสารเกี่ยวกับการเปรียบเทียบกับผู้จัดการบรรจุภัณฑ์อื่น ๆแต่นี่เป็นบทสรุปสั้น ๆ :

• package.elดาวน์โหลด tarballs ทึบแสงจากเซิร์ฟเวอร์ส่วนกลางโดยไม่มีตัวเลือกสำหรับการเลือกแพคเกจเวอร์ชันเฉพาะและไม่อนุญาตให้คุณทำการเปลี่ยนแปลงแพ็กเกจในเครื่องของคุณ สนับสนุนการเปลี่ยนแปลงต้นน้ำเป็นไปไม่ได้ straight.elโคลนที่เก็บ Git ด้วยวิธีการกระจายอำนาจ (แต่จะใช้สูตรจากMELPA , GNU ELPAและEmacsMirrorโดยอัตโนมัติหากคุณต้องการ) และช่วยให้คุณทำการเปลี่ยนแปลงในท้องถิ่นโดยพลการกระทำการเปลี่ยนแปลงเหล่านั้น สิ่งนี้สามารถทำได้ด้วยตนเองหรือคุณสามารถใช้การดำเนินการจัดการพื้นที่เก็บข้อมูลจำนวนมากในตัว ตรวจพบการเปลี่ยนแปลงแพ็คเกจของคุณโดยอัตโนมัติและไม่จำเป็นต้องสร้างใหม่ด้วยตนเอง นอกจากนี้straight.el รองรับการทำซ้ำที่สมบูรณ์สำหรับการกำหนดค่า Emacs ของคุณเนื่องจากช่วยให้คุณสามารถเขียนล็อคการแก้ไขที่มีการแฮช Git ของแพ็คเกจทั้งหมดของคุณ
• ทั้ง QuelpaและCaskมีพื้นฐานมาจากpackage.elและได้รับข้อเสียเดียวกันหลายประการ ตัวอย่างเช่น Cask ไม่มีแนวคิดในการติดตั้งแพ็คเกจรุ่นใดรุ่นหนึ่ง Quelpa ทำเช่นนั้น แต่คุณต้องเข้ารหัสแฮช Git ลงในไฟล์ init ของคุณ straight.elละทิ้งpackage.elทั้งหมดแทนที่การทำงานหลักทั้งหมดของมันด้วยการออกแบบแบบครบวงจรที่เหมาะกับกรณีการใช้งานอื่น ๆ อีกมากมาย
• el-getมีข้อได้เปรียบที่คุณสามารถติดตั้งแพ็คเกจได้จากทุกที่ (ทุกระบบรู้จักเวอร์ชันควบคุม, HTTP โดยพลการ, ผู้จัดการแพ็คเกจระบบ, EmacsWiki, แม้แต่go get!?) อย่างไรก็ตามการสนับสนุนแหล่งที่มาจำนวนมากทำให้ el-get ไม่สามารถให้การดำเนินการจัดการแพคเกจขั้นสูง (เช่นการทำซ้ำผ่านการล็อกไฟล์การแก้ไขและการดำเนินการจัดการพื้นที่เก็บข้อมูลแบบโต้ตอบ) ที่straight.elมีให้ straight.elรองรับ Git เท่านั้นเนื่องจากแพ็คเกจส่วนใหญ่มีให้บริการผ่าน Git และแพคเกจที่ไม่สามารถหาได้จากEmacsMirror (ฉันกล้าให้คุณหาแพ็คเกจที่ไม่สามารถเป็นได้!) โปรดทราบว่าstraight.elอย่างไรก็ตามยังมี API แบบขยายได้สำหรับแบ็กเอนด์ควบคุมเวอร์ชันเพิ่มเติม (เช่น Mercurial) ที่จะเพิ่มในอนาคตหากต้องการ
• บอร์กมีปรัชญาที่คล้ายกันมากstraight.elและให้ประโยชน์เหมือนกันหลายประการ แต่ก็ไม่ได้ออกแบบมาเพื่อเป็นผู้จัดการแพคเกจเต็มรูปแบบและถูกออกแบบมาเพื่อใช้ในการกังวลกับเครื่องมืออื่น ๆ เช่นepkg, auto-compileและ Magit ในทางกลับกันstraight.elมีข้อมูลในตัวและให้ทุกสิ่งที่คุณต้องการด้วยตัวเองโดยไม่ต้องการการกำหนดค่าเพิ่มเติม นอกจากนี้ Borg ยังใช้ Git submodules ซึ่งส่วนต่อประสานนั้นมีขอบที่ขรุขระในขณะที่straight.elใช้ที่เก็บ Git ที่จัดการอย่างอิสระทำให้มีความยืดหยุ่นและพลังงานเพิ่มขึ้น
• นอกจากนี้ยังมีแนวทางแบบแมนนวล แต่ฉันไม่แนะนำสิ่งนี้ หลังจากสองสามเดือนแรกคุณจะได้รับ Borg นวัตกรรมใหม่ straight.elหลังจากนั้นไม่กี่เดือนถัดไปของคุณจะมีนวัตกรรมใหม่ คุณจะได้เรียนรู้มากมายเกี่ยวกับการจัดการแพ็กเกจ;)

ในขณะที่มีข้อดีและข้อเสียฉันคิดว่า el-get ยังคงมีความเกี่ยวข้องแม้จะมีความคิดเห็นที่แข็งแกร่งของ @lunaryon (จงทบทวนเช่นกัน)

ผมใช้ดิบpackage.elกับการใช้แพคเกจสำหรับในขณะที่ (2-3 ปี) แล้วเปลี่ยนไปEl-GETแล้วถัง ฉันกลับไปที่เอลรับไม่กี่วันที่ผ่านมา แพ็คเกจก่อนหน้านี้เช่นเดียวกับคนอื่น ๆ ฉันจัดการด้วยตนเองด้วยตนเอง

ทำไมฉันกลับไปที่el-get ? ฉันพบความแปลกประหลาดของถังเกี่ยวกับสิ่งที่ไม่เป็น repit git (แพ็คเกจ Github ของฉันที่ไม่ได้อยู่ใน MELPA) ในขณะที่แพ็คเกจนั้นใช้ git จริง ๆ ... ฉันไม่ได้สนใจตรวจสอบหรือสร้างตั๋วเพียงดึงเก่าการกำหนดค่า el-getและฉันดีไปในเวลาไม่นาน

บางสิ่งที่ฉันชอบเกี่ยวกับel-get :

• รองรับหลาย fetchers ไม่ใช่แค่ git
• มันมีสูตรที่กำหนดไว้ล่วงหน้าเพียงพอ
• เร็วกว่าCaskเมื่อเริ่มต้น
• และใช่ @lunaryorn, Wiki ไม่ใช่ที่สำหรับแจกจ่ายรหัส แต่ฉันยังไม่ต้องการสร้าง repo Github หากไม่มีการโคลนบนemacsmirror (Github)
• มีอยู่ในตัวด้วยCaskคุณต้องติดตั้งภายนอก ฉันใช้ไฟล์ init เดียว (ไม่ใช่การกำหนดค่าแบบแยกส่วน) พร้อมโหมด alloutเพื่อสำรวจส่วนต่างๆ
• el-getนั้นง่ายพอจากมุมมองของผู้ใช้

หมายเหตุ: ฉันใช้ Emacs Git HEAD ภายใต้ OSX และ Linux

paradoxคุณอาจต้องการที่จะมีลักษณะที่ มันไม่ใช่ผู้จัดการบรรจุภัณฑ์คนอื่น แต่เป็นส่วนหน้าของผู้package.elดูแล ตัวอย่างเช่นเมื่อคุณอัปเดตแพ็คเกจจะถามว่าคุณต้องการติดตั้งและลบแพ็คเกจเก่าในขั้นตอนเดียวหรือไม่

หากคุณใช้มันคุณอาจต้องการชุดparadox-execute-asynchronouslyไปtในแฟ้ม init ของคุณ