4

I have been a vim user for years now and recently started to try out emacs. There are a lot of components available for this editor, like mail clients, IRC clients, etc. All these components need a package manager to update them and to make handling of them easier in general.

On vim there is a plethora of plugin managers (like Vundle or pathogen) and different people use different things.

On the other side, emacs includes package.el with recent versions (which is great to begin with), but there is also el-get and the package.el package list is pretty short.

Should I stick to package.el (and maybe extend the package list with marmalade)? Or do I need el-get for sane package management?

Drew
  • 29,895
  • 7
  • 74
  • 104
Wilhelm Schuster
  • 77
  • 2
  • 6
  • 1
    Also have a look at MELPA: http://melpa.milkbox.net/ – legoscia Jul 21 '14 at 14:19
  • 2
    http://melpa-stable.milkbox.net/ has fewer packages than its unstable older sibling, but it has sane version numbers and, well, stable packages. Personally I like el-get and use it for everything, but package.el is certainly the path of least resistance. – phils Jul 21 '14 at 14:45
  • el-get can encompass both ELPA [(see the github page)](https://github.com/dimitri/el-get) and MELPA [(see this SO thread)](http://stackoverflow.com/questions/23165158/how-do-i-install-melpa-packages-via-el-get), so it's probably your most flexible option. – Dan Jul 21 '14 at 14:49
  • @phils: FWIW: So far, I have to disagree about melpa-stable.milkbox.net. *None* of my libraries are listed there, for some reason. And they are all on "ordinary" MELPA. Yet they all are uploaded from *securely locked* EmacsWiki locations. So far, it is unclear just what distinguishes the two sites, and what "curating" is involved. (I'm waiting to hear back from Donald Curtis about this.) – Drew Jul 21 '14 at 15:18
  • @phils: I heard back from Donald about this. From his point of view, the "stable" MELPA site is in maintenance mode only. And the only reason that code like mine is not there is that no one has implemented uploading from the wiki for the "stable" site. Also, there is no "curating" done by anyone - no filtering to determine whether a package is stable, risky etc. The existence of two sites was requested by some package *developers* who wanted to distinguish dev versions of their packages from older ("stable") versions. – Drew Jul 21 '14 at 16:21
  • For sure; I would expect melpa-stable (like melpa) to work automatically, periodically detecting the latest revisions available. The difference being that melpa-stable only considers revisions which have been tagged as a release by their author. As you point out, there are package sources for which that interaction has not been implemented. I certainly agree that people should be aware of "ordinary" melpa as a (larger) source of packages, though -- and a great many people are very happy using it for pretty much everything, so clearly YMMV. – phils Jul 21 '14 at 22:11

1 Answers1

10

If you use a recent Emacs version then go with package.el. And add MELPA to the repository list.

Also, it is not the case that all "packages" (or libraries) need a package manager to update them and to make handling of them easier in general. There is a world of useful Emacs Lisp code out there that is not "packaged" and uploaded to a package.el repository.

More importantly, regardless of whether you use package.el to retrieve and "install" packages, you should learn the basics of loading, byte-compiling, and using Emacs Lisp code. Don't just use package.el blindly, without understanding something about Lisp code.

The basics of "installing" Lisp code manually include the following:

  1. In general, you will want to byte-compile libraries that you use, for better performance. Keep in mind this caveat, if you do so:

    1a. Load any source files (*.el) that define Lisp macros that are needed by any of the other Lisp libraries you use.

    1b. Then byte-compile (the macro-defining libraries and) the libraries that use the macro-defining libraries. This is important. It is likely that the latest versions of the macro-using libraries need the latest versions of the macros, and if you compile them without having first loaded the latest macro definitions then you are asking for trouble.

  2. Put any libraries you use in a directory that is in your load-path. Said differently: set variable load-path in your init file (~/.emacs) to a value that includes all directories containing Lisp code that you use.

  3. Generally, you want to use (require 'foo) in your own code (e.g. in your init file), to load library foo.

  4. However, #3 works only if library foo (file foo.el) actually provides feature foo: (provide 'foo). If it does not, you can use (load-library "foo") instead.

    (Note the difference here between using 'foo and "foo": the first refers to feature foo; the second refers to files foo.el and foo.elc.

  5. Finally, before you try to use a library, do yourself a favor and take a look at the Commentary section of the file header. Often it tells you important things about using the library. And even when it does not say something terribly important it might say something useful (e.g. a tip or two).

I mention 1-5 because I see too many (no, not many, but too many) new users just "installing" stuff using a package manager and never taking a look at what the code they are installing is all about: what it is for, how to use it, etc. If there is something in the Commentary then read it; the library author put it there to help you.

Beyond that, have fun!

Drew
  • 29,895
  • 7
  • 74
  • 104