패키지 관리자가 Emacs 패키지 관리자를 사용하지 않기위한 기술적 고려 사항

나는 주목할만한 패키지 관리자가 Emacs 패키지 관리 시스템 (ESS?)을 사용하지 않기로 선택했거나 제한 사항 (Helm)에 대해 불만을 나타냅니다.

Helm 의 README.md 에서 인용 :

경고 : Helm 파일을 가져 와서 컴파일하는 package.el 개념이 잘못되어 사용자가 melpa 및 list-package에서 업그레이드 할 때 대부분 오류가 발생했습니다. 이 비동기를 피하기 위해 깨끗한 환경에서 package.el이 파일을 컴파일하도록 강제하기위한 종속성으로 추가되었습니다. git에서 설치하고 make 파일을 사용하는 사람들은이 문제로 고통받지 않으며 (m) elpa에서 package.el로 설치할 수있는 다른 모든 패키지의 설치를 수정하므로 권장하지 않지만 비동기는 필요하지 않습니다. 자세한 내용은 FAQ를 참조하십시오.

현재의 패키지 관리 시스템이 암시 할 수있는 정확한 기술적 한계는 무엇이며, 패키지를 async종속성 으로 사용해야하는 이유는 무엇입니까?

package package-repositories ess

— 아멜리오 바스케스 레이나
소스

이 질문은이 사이트에 비해 너무 광범위해야합니다. 토론 포럼을 목표로하는 것이 좋습니다. help-gnu-emacs@gnu.org 또는 emacs-devel@gnu.org 또는 Emacs reddit 등을 사용해보십시오. " 정확한 문제는 무엇입니까? "는 그러한 문제가 하나 있다고 가정하고 어떤 패키지 (또는 패키지 관리자)에 대해 가능한 문제가 무엇인지 묻는 것이 너무 광범위하다고 가정합니다.

— Drew

ESS는 Melpa : melpa.org/#/ess 에서 호스팅됩니다. 아마도 문서 일뿐입니다. 나는 일반적으로 시스템 패키지 관리자를 통해 설치할 수있는 많은 프로젝트를 알고 있지만 실제 이유없이 해당 옵션을 언급하지 않기로 선택합니다 (사이트에서 소스 / 바이너리를 다운로드하는 한 멀리 있다고 가정 할 수 있음) 해야 할 이유). 헬름이 어떤 문제를 겪었는지 모르겠습니다.

— wvxvw 2016 년

당신의 제목은 나에게 조금 이상합니다. "관리자"를 두 번 쓰려고합니까, 아니면 관리자를 의미 했습니까?

— Malabarba

ESS 개발자로서 글을 작성하여 문제를 개선 할 수있는 방법을 알려주세요. 다른 사람들이 언급했듯이 ESS는 MELPA에 있습니다.

— Stephen Eglen

답변:

언급 한 문제는 아마도 해당 패키지가 이미 사용중인 Emacs 세션에서 패키지를 업그레이드 할 때 이전 버전의 패키지가 새 버전을 컴파일하는 동안 방해하여 파일이 잘못 컴파일 될 수 있다는 것입니다.

Emacs-25에는 임시 해결책이 있지만 AFAIK는 24.5에 여전히 존재합니다.

— 스테판
소스

ProofGeneral을 제외하고는 일부 ELPA 아카이브에서 사용할 수없는 주요 Emacs 패키지를 알지 못합니다. 특히 ESS는 3 년 이후 MELPA에 있습니다. 그리고 PG는 독자적인 이야기이며, 전체 Emacs 생태계를 대표하지는 않습니다.

ELPA는 분명히 결함이 있지만 대다수 패키지의 경우 Magit과 같은 큰 패키지에서도 잘 작동합니다. Helm은 ELPA에 대해 불평하는 유일한 패키지입니다. 나는 그들이 정확히 무엇에 대해 불평하는지 모르겠지만 컴파일에 관한 것 같습니다.

업그레이드 중 Emacs는 이전 버전이 여전히로드 된 환경에서 패키지의 새 버전을 컴파일합니다. 일반적으로 이것은 전혀 해를 끼치 지 않지만 특정 상황에서 매크로를 손상시킬 수 있습니다. Emacs는 매크로 의 이전 구현에 대해 새 버전을 컴파일하므로 새 코드가 해당 매크로의 특정 변경 사항에 의존하는 경우 파손될 수 있습니다.

그러나 패키지 관리자 인 나는이 진술에 동의하지 않습니다. ELPA 나 Emacs보다는 Helm을 비난하는 경향이 있습니다. 내 의견으로는 그 진술은 과장된 것이며 문제는 매크로이지만 과잉 및 남용 매크로의 증상입니다.

많은 매크로를 사용하고 심지어 더 나쁜 매크로를 매크로 본문에 넣는 경우 바이트 컴파일에 미치는 영향을 알고 있어야하며 자체 매크로와의 호환성을 유지하기 위해주의해야합니다 당신의 포장 안에. 그렇게하지 않고, 대신 비난을하는 것은 아주 좋은 일이 아닙니다. 내 2 센트

— 루나 리온
소스

FWIW, 나는 당신의 의견에 동의하지 않습니다 : 나는 매크로를 과도하게 사용하지 않는 것이 낫다는 것에 동의하지만, 컴파일 문제는 실제적이고 매크로 호출보다 더 많은 영향을 줄 수 있습니다 (예 : 그것들은 inlinable 함수 나 매크로 확장 중). 그리고이 문제에 물렸을 때 .elc 파일이 잘못되고 모든 종류의 재미있는 방식으로 오작동 할 수 있으므로 문제를 진단하기가 어려우며 문제를 해결하려면 패키지를 제거하고 다시 설치해야합니다 (한 번 생각하면 문제 및 어떤 패키지를 다시 설치해야

— Stefan

@ 스테판 나는 컴파일 문제를 거부하지 않습니다. 나는 스스로 물렸다. 그러나 나는이 진술을 통해 빛나는 태도와 내가 "균형 적 관점"이라고 부르는 것의 부족을 싫어한다. Helm은 그들의 측면에서 많은 실수를했기 때문에 그렇게 나쁜 것을 물었지만 그들의 진술은 그것을 인정하지 않습니다. 내 겸손한 견해에서 거시적 몸에서 함수를 호출하는 것은 그런 실수입니다. 매크로는 구문만을위한 것이지만 기능을위한 것은 아닙니다. 그러나 나는 이것이 Emacs Lisp 커뮤니티가 많은 다른 의견을 가지고있는 주제 인 것 같습니다.

— lunaryorn

ropemacs , jdee-emacs 및 excorporate 는 ELPA 아카이브에없는 중요한 패키지입니다 (주요 패키지의 기준에 따라 다름). 그러나 대부분의 패키지가 있습니다.

— Wilfred Hughes