"why el-get?" vs. *ELPA etc. is not documented
aspiers opened this issue · comments
http://www.emacswiki.org/emacs/el-get has some nice text on how el-get is different to *ELPA, and why it's useful. However this seems to be completely missing from the manual, and that's quite a significant omission, because anyone who didn't find the emacswiki page will wonder why on earth they would need el-get. This also ties into #1169.
I guess the two main use cases for el-get that ELPA doesn't cover are:
- Packages that need to run arbitrary build commands when you install them;
- Easily installing arbitrary pieces of Elisp code that aren't already available as ELPA packages (we can call this "client-side packaging".
@DarwinAwardWinner sorry if the title of this issue was misleading. I'm not asking "why el-get?" for myself, because the answer is already in emacswiki. I'm asking for the answer to be clearly documented in the manual, so that others don't remain confused about what el-get offers. I've updated the issue title accordingly.
also I see In yasnippet @npostavs is working on documentation setup. auto generation from doc strings and stuff. We can also adopt that in here as well and put up on github pages.
what would others say.?
You can find bits and pieces of the answer at http://tapoueh.org/blog/2012/08/28-el-get-new-stable-release and http://tapoueh.org/emacs/el-get.html and the EmacsWiki entry about el-get. I would accept a patch to the main manual adding a section about that, yes.
I think it would be good to distinguish el-get from ELPA, since in
practical terms for the end user,ELPA covers a lot more of el-get's uses
than it used to.
On Dec 12, 2013 11:17 PM, "yagnesh రాఘవ" notifications@github.com wrote:
also I see In yasnippet @npostavs https://github.com/npostavs is
working on documentation setup. auto generation from doc strings and stuff.
We can also adopt that in here as well and put up on github pages.what would others say.?
—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1468#issuecomment-30491026
.
It may be of interest that a non-trivial package like helm seems to prefer a straight git install (like el-get provides) instead of built-in packaging system: https://github.com/emacs-helm/helm/blob/master/README.md#install-from-emacs-packaging-system
The lack of clarity on the purpose and differences of el-get are resulting in el-get being unfairly characterized as obsolete elsewhere, as observed in cask/cask#265.
Yes, some people do not consider rudeness a weakness in disguise. I find cask interesting, but too far off the Emacs's path.
Anybody can develop and use what one feels are better tools, of course. I admire cask developers, even if perhaps more civility would be appreciated in an open source community.
Still, if one cares for Emacs's roots, elegance and unique principles (heritage from the Lisp world), falling back on Python feels a little a de-evolution to me, no offense intended of course, just my low-ranking perspective.
Based on further information revealed in cask/cask#265, it does seem that some of the previously unique selling points of el-get (such as installation directly via an SCM or from other build commands) are now also covered by Quelpa and/or Cask. Also I am hearing claims that they are more "standards-compliant" than el-get in their usage of package.el, MELPA recipes etc. It would be very useful to understand to what extent this is true, and whether there are any opportunities for integration or even convergence between the different approaches.
Of course freedom of choice is generally good and healthy, but conversely too much fragmentation in the community can be harmful. Many other communities (Ruby, Python, most Linux distros, to name but a few) have thrived by standardizing on a unified approach to package management. Just saying ... ;-)