From: Tomi Ollila <tomi.ollila@iki.fi>
To: Adam Wolfe Gordon <awg+notmuch@xvx.ca>,
	Damien Cassou <damien.cassou@gmail.com>
Subject: Re: emacs: Handling external dependencies
In-Reply-To:
 <CAMoJFUt8hvVF4svNdgKNPrDTTRWFn9+AWbBWL6egwy7jYnOqZg@mail.gmail.com>
References:
 <CA+y5ggiGrAcicQLeskaXFoxYyJQVVXZ1VRX=XS8zPFR9_mBFxA@mail.gmail.com>
	<CAMoJFUt8hvVF4svNdgKNPrDTTRWFn9+AWbBWL6egwy7jYnOqZg@mail.gmail.com>
User-Agent: Notmuch/0.14+84~g8a199bf (http://notmuchmail.org) Emacs/24.2.1
	(x86_64-unknown-linux-gnu)
Date: Wed, 14 Nov 2012 11:48:23 +0200
Message-ID: <m2lie4347s.fsf@guru.guru-group.fi>
MIME-Version: 1.0
Content-Type: text/plain
Cc: notmuch mailing list <notmuch@notmuchmail.org>
Precedence: list

On Wed, Nov 14 2012, Adam Wolfe Gordon <awg+notmuch@xvx.ca> wrote:

> Hi Damien,
>
> On Sat, Nov 10, 2012 at 8:58 AM, Damien Cassou <damien.cassou@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).

Now that Adam said it I have to agree. IMO design the feature so that it
is disabled unless `header-button` is available. 

> Just my thoughts - offering them mostly since no one else has replied.
>
> -- Adam

Tomi