emacs: Handling external dependencies

[Adam Wolfe Gordon]

Hi Damien,

On Sat, Nov 10, 2012 at 8:58 AM, Damien Cassou <damien.cassou at gmail.com> wrote:
> I recently sent a patch for notmuch emacs that depends on a particular
> library. What is the best way to deal with such dependencies?

First off, what's the library, and what is it used for?

I believe that currently the notmuch emacs interface only depends on
stuff that's included with emacs, which is a nice way to be. There are
some packages that can improve the notmuch emacs experience if they
are installed, like w3m. If possible, I'd encourage you to make the
new library recommended, rather than required.

> I can see different solutions:
>
> 1) distribute a rewritten version of the dependency so that the code
> now belongs to notmuch (e.g., replace the name of the library by
> 'notmuch'). This has the disadvantage of requiring maintenance when a
> new version of the library is released and can also be considered
> 'stealing' by some authors.
>
> 2) use a package manager to load the library. This has the
> disadvantage that the now standard package manager is not in
> widespread use yet and is not compatible with other OS-based package
> managers (such as apt-get in Debian).
>
> 3) distribute the dependency with the rest of notmuch and load this
> one. This has the disadvantage of possibly shadowing an already
> existing version of this library installed through a different means.
>
> 4) distribute the dependency with the rest of notmuch (in a separate
> "fallback-libs/" directory) and load it only when requiring the
> library with the standard load-path does not work. Jonas Bernoulli
> gave me a way to do that:
>
> ,----
> | (or (require 'THE-LIB nil t)
> |     (let ((load-path
> |           (cons (expand-file-name
> |                  "fallback-libs"
> |                  (file-name-directory (or load-file-name buffer-file-name)))
> |                 load-path)))
> |       (require 'THE-LIB)))
> `----
>
> What do you think?

I'm not big on any of these solutions. I'd suggest just using the
package, documenting it as a dependency, and letting users install it
however they like. This means adding it as a dependency to the
distro-specific packaging (easy for Debian and friends, not sure about
others).

Just my thoughts - offering them mostly since no one else has replied.

-- Adam