tło

Używam emacsa codziennie, ale głównie po to, aby załatwić sprawę. Nie lubię dostosowywać tego bardziej niż dodawanie pakietów i nie lubię rozwiązywania problemów. Chcę, aby emacs znikał w tle, tak jak robi to dobry system operacyjny, i po prostu załatwiał sprawy. Jakiś czas temu odkryłem, że el-getpozwoliło mi to zainstalować pakiety, których potrzebowałem, a które były niedostępne, package.ela także dało mi większą kontrolę, na przykład wybór maintgałęzi trybu Org zamiast krwawienia, co może powodować tymczasowe problemy. Teraz nie jestem pewien, czy powinienem używać, el-getczy nie.

Pytanie

el-getwydawało się być świetnym rozwiązaniem dla różnych repozytoriów i hacków emacsa. Oferował możliwości, które były po prostu niemożliwe package.el. Teraz, gdy package.elw nowszych wersjach emacs ( >=24.4) obsługuje wiele repozytoriów, jakie są przypadki użycia el-geti podobne alternatywy dla wbudowanego menedżera pakietów emacsa?

Są rzeczy, które wciąż są niemożliwe z ELPA, i są rzeczy, które zawsze będą niemożliwe z ELPA, ponieważ nie pasują do koncepcji ELPA: Nigdy nie będziesz w stanie zainstalować konkretnego zatwierdzenia przez jego skrót z rozwidlenia magazyn. Podobnie, nigdy nie będziesz w stanie zastosować niestandardowych lokalnych poprawek do pakietu przed jego zainstalowaniem. Funkcje te są po prostu poza zakresem ELPA, a jeśli będziesz ich potrzebować, będziesz musiał użyć alternatywnego menedżera pakietów.

Myślę jednak, że el-get jest obecnie rodzajem rozwiązania starszego typu. Biorąc pod uwagę, że ELPA stała się de facto standardowym menedżerem pakietów dla Emacsa, menedżerowie alternatywnych pakietów powinni bezproblemowo zintegrować się z ELPA. el-get nie ujawnia jednak własnych pakietów ELPA, co oznacza, że ​​jego pakiety są całkowicie niewidoczne dla ELPA, a pakiety ELPA nigdy nie mogą zależeć od pakietów el-get, co ma oczywiste implikacje dla zarządzania zależnościami.

Jeśli potrzebujesz funkcji wykraczających poza ELPA, powinieneś teraz spojrzeć na QUELPA zamiast el-get.

Napisałem nowego menedżera pakietów dla Emacsa straight.el, który próbuje ulepszyć wszystkie istniejące rozwiązania do zarządzania pakietami. Dokumentacja zawiera obszerną sekcję straight.eldotyczącą porównań z innymi menedżerami pakietów , ale tutaj jest bardzo krótkie podsumowanie:

• package.elpobiera nieprzezroczyste pliki tar z serwerów centralnych, bez opcji wyboru konkretnej wersji pakietu i nie pozwala na wprowadzanie lokalnych zmian w pakietach; przyczynianie się do zmian na wcześniejszych etapach jest niemożliwe. straight.elklonuje repozytoria Git w sposób zdecentralizowany (ale automatycznie używa receptur z MELPA , GNU ELPA i EmacsMirror , jeśli chcesz) i pozwala na wprowadzanie w nich dowolnych lokalnych zmian, zatwierdzanie tych zmian i przyczynianie się w górę. Można to zrobić ręcznie lub użyć wbudowanych operacji zarządzania repozytorium masowym. Zmiany w pakietach są wykrywane automatycznie, a ręczne przebudowy nie są wymagane. Ponadto,straight.el obsługuje pełną odtwarzalność konfiguracji Emacsa, ponieważ pozwala napisać plik blokady wersji, który zawiera skróty Git wszystkich twoich pakietów.
• Quelpa i Cask są oparte na package.eltych samych wadach i dziedziczą je. Na przykład Cask nie ma pojęcia o instalacji konkretnej wersji pakietu. Quelpa tak, ale wymaga zakodowania skrótu Git w pliku inicjującym. całkowicie straight.elunika package.el, zastępując całą swoją podstawową funkcjonalność ujednoliconym wyglądem dostosowanym do wielu innych zastosowań.
• el-get ma tę zaletę, że można instalować pakiety z dowolnego miejsca (wszystkie znane systemy kontroli wersji, dowolny protokół HTTP, menedżery pakietów systemowych, EmacsWiki, nawet go get!?). Jednak, obsługując tak wiele źródeł, el-get nie może zapewnić rodzaju zaawansowanych operacji zarządzania pakietami (takich jak odtwarzalność poprzez pliki blokujące wersje i operacje zarządzania interaktywnym repozytorium), które straight.elzapewnia. straight.elobsługuje tylko Git, ponieważ większość pakietów jest dostępna za pośrednictwem Git, a tych, których nie ma, można uzyskać za pomocą EmacsMirror (odważę się znaleźć taki, który nie może być!). Należy straight.eljednak zauważyć, że zapewnia jednak rozszerzalny interfejs API dla dodatkowych backendów kontroli wersji (np. Dla Mercurial), które zostaną dodane w razie potrzeby w przyszłości.
• Borg ma bardzo podobną filozofię straight.eli daje wiele takich samych korzyści. Jednak nie ma być pełnym menedżer pakietów, i jest przeznaczony do stosowania w trosce o innych narzędzi, takich jak epkg, auto-compilei MAGIT. Przeciwnie, straight.eljest samowystarczalny i zapewnia wszystko, czego potrzebujesz, nie wymagając dodatkowej konfiguracji. Ponadto Borg używa podmodułów Git, których interfejs ma pewne szorstkie krawędzie, podczas gdy straight.elużywa niezależnie zarządzanych repozytoriów Git, co zapewnia dodatkową elastyczność i moc.
• Istnieje również podejście ręczne, ale nie polecam tego. Po pierwszych kilku miesiącach na nowo odkryłbyś Borga. Po następnych kilku miesiącach wymyślilibyście na nowo straight.el. Dowiesz się jednak dużo o zarządzaniu pakietami;)

Chociaż istnieją plusy i minusy, myślę, że el-get jest nadal aktualny, pomimo silnych opinii @lunaryon (również odmawianie).

Przez jakiś czas korzystałem z raw package.el z pakietem use (2 do 3 lat), potem przestawiłem się na el-get , potem Cask . Wróciłem do el-get kilka dni temu. Wcześniej package.el , podobnie jak wiele innych, ręcznie obsługiwałem dodatki.

Dlaczego wróciłem do el-get ? Zetknąłem się z pewną dziwnością Cask dotyczącą tego, że nie jest to repozytorium git (mój pakiet Github, którego nie ma w MELPA), podczas gdy ten pakiet faktycznie używa git ... Nie zawracałem sobie głowy badaniem ani tworzeniem biletu, po prostu wyciągnąłem mój stary el-get config i byłem gotowy, aby przejść w krótkim czasie.

Kilka rzeczy, które lubię w el-get :

• Obsługuje wielu ściągaczy, nie tylko git.
• Zawiera wystarczającą liczbę wstępnie zdefiniowanych przepisów
• Szybszy niż Cask przy uruchomieniu.
• i tak @lunaryorn, Wiki nie jest miejscem do rozpowszechniania kodu, nadal nie chcę tworzyć repozytorium Github, jeśli nie ma klonu emacsmirror (Github).
• Samodzielny, z Cask potrzebujesz instalacji zewnętrznej. Używam jednego pliku inicjującego (nie konfiguracji modułowej) z trybem allout do nawigacji po sekcjach.
• el-get jest dość prosty z punktu widzenia użytkownika.

Uwaga: korzystam z Emacs Git HEAD w systemach OSX i Linux.

Możesz rzucić okiem paradox. To nie jest kolejny menedżer pakietów, ale fajniejszy interfejs package.el. Na przykład podczas aktualizacji pakietów pyta, czy chcesz je zainstalować i usunąć stare w jednym kroku.

Jeśli używamy go, prawdopodobnie chcesz, aby zestaw paradox-execute-asynchronouslydo tzapisania w pliku inicjującego.