배경

나는 매일 이맥스를 사용하지만 대부분 일을 끝내기 위해 사용합니다. 패키지를 추가하는 것 이상으로 사용자 정의하는 것을 좋아하지 않으며 문제 해결을 좋아하지 않습니다. 나는 이맥스가 좋은 OS가하는 방식을 배경으로 희미 해지기를 원하고 일을 시작하기를 원한다. 얼마 전에 필자 el-get는 사용할 수 없었던 패키지를 설치할 수 있었고 일시적인 문제를 일으킬 수있는 번짐 가장자리보다는 조직 모드 package.el의 maint분기를 선택하는 등의 제어 기능 을 강화할 수있었습니다. 이제 사용 여부를 잘 모르겠습니다 el-get.

질문

el-get다양한 저장소와 이맥스에 대한 훌륭한 솔루션 인 것처럼 보였습니다. 그것으로는 불가능했던 기능을 제공했습니다 package.el. 이제 package.el이맥스 (의 최신 버전에 >=24.4) 지원하는 여러 저장소, 유스 케이스 무엇 el-get이맥스의와 유사한 대안이 내장 패키지 관리자?

ELPA에는 여전히 불가능한 것들이 있으며 ELPA의 개념에 맞지 않기 때문에 ELPA에서는 항상 불가능한 것들이 있습니다. 포크에서 해시로 특정 커밋을 설치할 수는 없습니다. 저장소. 마찬가지로, 패키지를 설치하기 전에 사용자 정의 로컬 패치를 패키지에 적용 할 수 없습니다. 이러한 기능은 단순히 ELPA의 범위를 벗어나므로 필요한 경우 대체 패키지 관리자를 사용해야합니다.

하지만 요즘에는 그 엘겟이 일종의 레거시 솔루션이라고 생각합니다. ELPA가 사실상 Emacs의 표준 패키지 관리자가되었으므로 대체 패키지 관리자는 ELPA와 완벽하게 통합되어야합니다. 그러나 el-get은 자체 패키지를 ELPA에 노출시키지 않습니다. 즉, 패키지가 ELPA에 완전히 표시되지 않으며 ELPA 패키지는 el-get 패키지에 의존 할 수 없으며 종속성 관리에 명백한 영향을 미칩니다.

ELPA 이외의 기능이 필요한 경우 현재 el-get 대신 QUELPA를 살펴보십시오.

straight.el기존의 모든 패키지 관리 솔루션을 개선하려는 Emacs의 새로운 패키지 관리자를 작성했습니다 . 거기에있다 광범위한 섹션 straight.el에 대한 문서는 다른 패키지 관리자에 대한 비교는 , 그러나 여기 아주 짧은 요약 한 것입니다 :

• package.el특정 버전의 패키지를 선택할 수있는 옵션없이 중앙 서버에서 불투명 한 타르볼을 다운로드하며 패키지를 로컬로 변경할 수 없습니다. 업스트림 변경에 기여하는 것은 불가능합니다. straight.elGit 리포지토리를 분산 방식으로 복제하지만 원하는 경우 MELPA , GNU ELPA 및 EmacsMirror의 레시피를 자동으로 사용 하며 임의로 로컬 변경을 수행하고 변경 사항을 커밋하고 업스트림에 기여할 수 있습니다. 이를 수동으로 수행하거나 내장 대량 저장소 관리 조작을 사용할 수 있습니다. 패키지 변경은 자동으로 감지되며 수동 재 구축이 필요하지 않습니다. 더욱이,straight.el 모든 패키지의 Git 해시를 포함하는 개정 잠금 파일을 작성할 수 있으므로 Emacs 구성에 대한 완전한 재현성을 지원합니다.
• 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을 통해 사용 가능하며 EmacsMirror 를 통해 얻을 수없는 패키지는 가능하므로 Git 만 지원합니다 . 참고 straight.el원하는 경우, 그럼에도 불구하고 추가 버전 관리 백엔드위한 확장 API (예 의욕에 대한)를 제공은 향후에 추가합니다.
• Borg 는 매우 유사한 철학을 가지고 있으며 straight.el동일한 장점을 많이 제공합니다. 그러나 전체 패키지 관리자로 설계되지 않았 epkg으며 auto-compile, 및 Magit와 같은 다른 도구와 관련하여 사용되도록 설계되었습니다 . 반대로, straight.el자체 포함되어 있으며 추가 구성이 거의 필요하지 않고 필요한 모든 것을 자체적으로 제공합니다. 또한, Borg는 인터페이스가 약간 거친 Git 서브 모듈을 사용하는 반면 straight.el독립적으로 관리되는 Git 리포지토리를 사용하여 추가 유연성과 성능을 제공합니다.
• 수동 접근 방식도 있지만 권장하지 않습니다. 처음 몇 달이 지나면 Borg를 다시 발명했을 것입니다. 다음 몇 달이 지나면 다시 발명했을 것 straight.el입니다. 패키지 관리에 대해 많이 배울 것입니다.;)

장단점이 있지만 @lunaryon (rejeep)의 강력한 의견에도 불구하고 el-get은 여전히 ​​관련이 있다고 생각합니다.

나는 raw package.el 을 use-package 와 함께 잠시 (2-3 년) 사용한 다음 el-get으로 전환 한 다음 Cask 로 전환했습니다 . 며칠 전에 엘 겟으로 돌아갔습니다. 이전 package.el 은 다른 많은 사람들과 마찬가지로 추가 기능을 수동으로 처리했습니다.

왜 돌아가 않았다 엘 얻을 ? 나는 git repo (MELPA에없는 Github 패키지)가 아닌 것에 대해 Cask의 이상한 점을 발견했다 . el-get config와 나는 곧 갈 수있어서 좋았습니다.

el-get 에 대해 내가 좋아하는 몇 가지 :

• git뿐만 아니라 여러 fetcher를 지원합니다.
• 사전 정의 된 레시피가 충분합니다.
• 시작시 Cask 보다 빠릅니다 .
• 그리고 예 @lunaryorn, Wiki는 코드를 배포하는 장소가 아니지만 emacsmirror (Github) 에 복제본이 없다면 여전히 Github 저장소를 만들고 싶지 않습니다 .
• 자체 포함되어 있으며 Cask 를 사용하면 외부 설치가 필요합니다. 모듈을 구성하지 않는 단일 init 파일을 allout-mode 와 함께 사용하여 섹션을 탐색합니다.
• el-get 은 사용자 관점에서 충분히 간단합니다.

참고 : OSX 및 Linux에서 Emacs Git HEAD를 실행하고 있습니다.

를보고 싶을 수도 있습니다 paradox. 다른 패키지 관리자는 아니지만에 대한 깔끔한 프론트 엔드입니다 package.el. 예를 들어, 패키지를 업데이트 할 때 패키지를 설치할지 여부를 묻고 한 단계에서 이전 패키지를 삭제할 수 있습니다.

당신이 그것을 사용하는 경우, 당신은 아마 설정할 paradox-execute-asynchronously에 t당신의 init 파일에서.