BBDB v3 approaching release

BBDB v3 approaching release

[Roland Winkler]

BBDB v3 has matured on Savannah for quite some time and I want to
get it ready for a proper release.  Yet there are two things where
I'd appreciate some help:

- The current configure scripts and makefiles pretty much follow the
  old lines of BBDB v2.  I'd be glad if someone familiar with the GNU
  conventions for such files could look over these files so that
  they work reliably / as expected on different platforms.

- What needs to be done to actually release BBDB so that users can
  download the tar ball from some server?  How to arrange for
  something like a checksum so that users can trust the tar ball?

Any other comments are welcome, too.

Roland


BBDB is available at
http://savannah.nongnu.org/projects/bbdb/
To check it out, use
git clone git://git.savannah.nongnu.org/bbdb.git

Re: BBDB v3 approaching release

[Leo Liu]

On 2013-05-27 16:18 +0800, Roland Winkler wrote:
> - What needs to be done to actually release BBDB so that users can
>   download the tar ball from some server?  How to arrange for
>   something like a checksum so that users can trust the tar ball?

GNU ELPA is good for distribution.

Leo

Re: BBDB v3 approaching release

[Stefan Monnier]

>> - What needs to be done to actually release BBDB so that users can
>> download the tar ball from some server?  How to arrange for
>> something like a checksum so that users can trust the tar ball?
> GNU ELPA is good for distribution.

But it's only for code whose copyright was assigned to the FSF.
While BBDBv3 has a lot of new code by Roland, AFAICT it still shares
a non-trivial amount of code with the old codebase for which we don't
have copyright assignments.


        Stefan

Re: BBDB v3 approaching release

[Roland Winkler]

On Mon, May 27 2013, Stefan Monnier wrote:
>> GNU ELPA is good for distribution.
>
> But it's only for code whose copyright was assigned to the FSF.
> While BBDBv3 has a lot of new code by Roland, AFAICT it still shares
> a non-trivial amount of code with the old codebase for which we don't
> have copyright assignments.

Identifying the old pieces of code in BBDB v3, which do require
copyright assignments, is also on my to-do list. Maybe the amount of old
code is really not significant anymore. I cannot tell myself and it is a
somewhat tedious excercise to check this properly. (Help welcome!)
Yet I think that in the meanwhile, it would be nice to have a proper
release of BBDB v3.

Roland

Re: BBDB v3 approaching release

[Stefan Monnier]

> Yet I think that in the meanwhile, it would be nice to have a proper
> release of BBDB v3.

Definitely.
You can package it in the format used for ELPA packages (you don't even
need a Makefile for that).


        Stefan

Re: BBDB v3 approaching release

[Roland Winkler]

On Mon May 27 2013 Stefan Monnier wrote:
> You can package it in the format used for ELPA packages (you don't even
> need a Makefile for that).

From a more practical perspective, what would be suitbable routes
to distribute "it", if ELPA is currently not available for BBDB? 
("it" = a tar ball?)

Re: BBDB v3 approaching release

[Dmitry Gutov]

"Roland Winkler" <winkler@gnu.org> writes:

> On Mon May 27 2013 Stefan Monnier wrote:
>> You can package it in the format used for ELPA packages (you don't even
>> need a Makefile for that).
>
> From a more practical perspective, what would be suitbable routes
> to distribute "it", if ELPA is currently not available for BBDB? 
> ("it" = a tar ball?)

http://marmalade-repo.org/ and/or http://melpa.milkbox.net/.

The latter doesn't use tarballs, you just create a recipe and point it
to your repository.

Re: BBDB v3 approaching release

[Roland Winkler]

On Mon May 27 2013 Dmitry Gutov wrote:
> http://marmalade-repo.org/ and/or http://melpa.milkbox.net/.
> 
> The latter doesn't use tarballs, you just create a recipe and
> point it to your repository.

Maybe I am old-fashioned here: I had been thinking about releasing a
tar ball that comes with a configure script and makefiles to compile
and install BBDB. One reason for this is that BBDB includes tex
files required for printing BBDB. These files usually reside in some
tex directory outside the usual emacs tree.

(What happens to other packages hosted on savannah? How are they
released? Maybe this is also something I should look for on the
savannah mailing list.)

Or is all this really outdated??

Roland

Re: BBDB v3 approaching release

[Ulrich Mueller]

>>>>> On Mon, 27 May 2013, Roland Winkler wrote:

> Maybe I am old-fashioned here: I had been thinking about releasing a
> tar ball that comes with a configure script and makefiles to compile
> and install BBDB.

Please do. Packages without a build system impose additional work upon
all distros.

> One reason for this is that BBDB includes tex files required for
> printing BBDB. These files usually reside in some tex directory
> outside the usual emacs tree.

Ulrich

Re: BBDB v3 approaching release

[Roland Winkler]

On Tue May 28 2013 Ulrich Mueller wrote:
> Please do. Packages without a build system impose additional work
> upon all distros.

...which brings me back to part one of my original post:

  The current configure scripts and makefiles pretty much follow the
  old lines of BBDB v2.  I'd be glad if someone familiar with the GNU
  conventions for such files could look over these files so that
  they work reliably / as expected on different platforms.

Roland

Re: BBDB v3 approaching release

[Stefan Monnier]

>> Maybe I am old-fashioned here: I had been thinking about releasing a
>> tar ball that comes with a configure script and makefiles to compile
>> and install BBDB.
> Please do. Packages without a build system impose additional work upon
> all distros.

If the package follows the ELPA conventions, then it comes with a build
system.


        Stefan

Re: BBDB v3 approaching release

[Stefan Monnier]

>> You can package it in the format used for ELPA packages (you don't even
>> need a Makefile for that).
> From a more practical perspective, what would be suitbable routes
> to distribute "it", if ELPA is currently not available for BBDB? 
> ("it" = a tar ball?)

You can put the tarball anywhere you like.  People can then install it
via M-x package-install-file, which will byte-compile it, setup
autoloads, and put it under ~/.emacs.d/elpa along with any accompanying
files, so you should be able to find those .tex auxiliary files at
run-time without any difficulty.


        Stefan

Re: BBDB v3 approaching release

[Roland Winkler]

On Tue May 28 2013 Christian Egli wrote:
> > - The current configure scripts and makefiles pretty much follow the
> >   old lines of BBDB v2.  I'd be glad if someone familiar with the GNU
> >   conventions for such files could look over these files so that
> >   they work reliably / as expected on different platforms.
> 
> I know my way around autotools and have some understanding of the GNU
> conventions. I looked at configure.ac and Makefile.in. I could help.
> What exactly is it that you want to do? Just port the build system to
> more modern and standard autotools usage?

Hi Christian

Thanks! - One concern is about the options of the ./configure script
related to the installation of BBDB.  Say, currently the options
--prefix  and --datadir don't do anything meaningful.  But I don't
know what would be meaningful here.

I am really a novice with that stuff. So possibly there are more
problems hidden that I have not yet realized.

Roland

Re: BBDB v3 approaching release

[Stefan Monnier]

> I am really a novice with that stuff. So possibly there are more
> problems hidden that I have not yet realized.

You *really* want to stick to the ELPA format.
It's simple and straightforward for you, and for the end-users.


        Stefan

Re: BBDB v3 approaching release

[Roland Winkler]

On Tue May 28 2013 Stefan Monnier wrote:
> > I am really a novice with that stuff. So possibly there are more
> > problems hidden that I have not yet realized.
> 
> You *really* want to stick to the ELPA format.
> It's simple and straightforward for you, and for the end-users.

Thanks, I'll look into this.

Roland

Re: BBDB v3 approaching release

[Ulrich Mueller]

>>>>> On Tue, 28 May 2013, Stefan Monnier wrote:

> You *really* want to stick to the ELPA format. It's simple and
> straightforward for you, and for the end-users.

How do I configure install locations of a package if it's in ELPA
format? Especially, if the package has non-lisp components?

Ulrich

Re: BBDB v3 approaching release

[Stefan Monnier]

>> You *really* want to stick to the ELPA format. It's simple and
>> straightforward for you, and for the end-users.
> How do I configure install locations of a package if it's in ELPA
> format?

You don't.

> Especially, if the package has non-lisp components?

You leave them alongside the Elisp files.  And when you need them, your
Elisp package will find them by looking around itself (it can get
access to its own location via `load-file-name').


        Stefan

Re: BBDB v3 approaching release

[Roland Winkler]

On Wed May 29 2013 Stefan Monnier wrote:
> > How do I configure install locations of a package if it's in ELPA
> > format?
> 
> You don't.
> 
> > Especially, if the package has non-lisp components?
> 
> You leave them alongside the Elisp files.  And when you need them, your
> Elisp package will find them by looking around itself (it can get
> access to its own location via `load-file-name').

BBDB contains three TeX files that are required by plain TeX when
you want to print the database.  Here BBDB creates a TeX file that
contains for example

  \input bbdb-print
  \input bbdb-cols

In a texmf installation, these files would go into a directory like
/usr/local/share/texmf/bbdb 
I do not know where other TeX installations expect to find such files.

Can the ELPA format handle such files, too?  How?

In a way, I am surprised that I do not know about other elisp
packages having similar needs. Whenever you want to print something
with (La)TeX, you normally need some kind of style file that (La)TeX
needs to find.

Of course, one work around would be that emacs includes the style
file into the TeX files it generates. One advantage of such an
approach would be that the resulting TeX files become self-contained
for any "standard" TeX installation so that one can forward the TeX
files to someone who does not have the BBDB tex files installed.
But I consider the forwarding of such files a more rare scenario.

Roland

Re: BBDB v3 approaching release

[Jambunathan K]

> Can the ELPA format handle such files, too?  How?

ELPA is just a tar bundle.  You can include whatever you want as part of
the bundle. 




> In a way, I am surprised that I do not know about other elisp
> packages having similar needs. Whenever you want to print something
> with (La)TeX, you normally need some kind of style file that (La)TeX
> needs to find.

Org's ODT exporter depends on XML style files for it's export.  The
style files are included right within the tar ball as part of ./etc/
directory.

        See http://elpa.gnu.org/packages/org.html.

(I think using "./etc" for bundling "data files" is a good precedent.)

`load-file-name' is your friend.

    (defconst org-odt-lib-dir
      (file-name-directory load-file-name)
      "Location of ODT exporter.
    Use this to infer values of `org-odt-styles-dir' and
    `org-odt-schema-dir'.")

    (defvar org-odt-data-dir
      (expand-file-name "./etc/" org-odt-lib-dir)
      "Data directory for ODT exporter.
    Use this to infer values of `org-odt-styles-dir' and
    `org-odt-schema-dir'.")

> Of course, one work around would be that emacs includes the style
> file into the TeX files it generates. One advantage of such an
> approach would be that the resulting TeX files become self-contained
> for any "standard" TeX installation so that one can forward the TeX
> files to someone who does not have the BBDB tex files installed.
> But I consider the forwarding of such files a more rare scenario.

Bundle things in a way that minimizes headaches for you and others.

In the long run, you can do away with BDBD specific style files and use
some packages that (already) come with Tex.  Or move the BDBB style
files to Tex distribution.

2 cents.

> Roland

Re: BBDB v3 approaching release

[Stephen J. Turnbull]

Roland Winkler writes:

 > In a texmf installation, these files would go into a directory like
 > /usr/local/share/texmf/bbdb 
 > I do not know where other TeX installations expect to find such files.
 > 
 > Can the ELPA format handle such files, too?  How?

TeX is happy to pick up such files from the current directory.  Why
would it be a problem?  If that doesn't work or the BBDB includes are
shadowed, TEXINPUTS=.:$TEXINPUTS should do the trick.  man kpathsea
for more information about telling TeX where to find stuff.

But mostly people are going to do such formatting in a proper source
tree.  Not your problem.  The GPL (maybe, but certainly FLOSS
courtesy) requires that you provide a "script" (ie, Makefile) to
rebuild if people want to modify in-place, but for the info files that
can be as simple as

bbdb.info: bbdb.texi
	makeinfo bbdb.texi

bbdb.html: bbdb.texi
	makeinfo --html bbdb.texi

bbdb.pdf: bbdb.texi <style files ...>
	makeinfo --pdf bbdb.texi

At least, I should think so.  If you normally use @setfilename to put
the info etc someplace other than the current directory, use the -o
option to put it in the current directory.

Re: BBDB v3 approaching release

[Roland Winkler]

On Thu May 30 2013 Stephen J. Turnbull wrote:
> TeX is happy to pick up such files from the current directory.  Why
> would it be a problem?  If that doesn't work or the BBDB includes are
> shadowed, TEXINPUTS=.:$TEXINPUTS should do the trick.  man kpathsea
> for more information about telling TeX where to find stuff.

Normally the user directory where bbdb-print creates its TeX file is
not (should not be!) the directory where BBDB keeps its TeX include
files.

Re: BBDB v3 approaching release

[Stephen J. Turnbull]

Roland Winkler writes:
 > On Thu May 30 2013 Stephen J. Turnbull wrote:
 > > TeX is happy to pick up such files from the current directory.  Why
 > > would it be a problem?  If that doesn't work or the BBDB includes are
 > > shadowed, TEXINPUTS=.:$TEXINPUTS should do the trick.  man kpathsea
 > > for more information about telling TeX where to find stuff.
 > 
 > Normally the user directory where bbdb-print creates its TeX file is
 > not (should not be!) the directory where BBDB keeps its TeX include
 > files.

That's one good way to do it, but not necessarily normal.  An
installed ELPA package can (and IMO should) be thought of as a binary
whose internal structure happens to take advantage of the file system
to organize its parts rather than ELF sections or zipfile members.  In
this it's similar to a Python package or a Mac OS X .app.

People who want to fiddle with the internals of a package really
should do so in the *source* tree, not in the installed tree.  The
installed tree will have a more convenient layout for source browsing.

I'll grant that the info files are a special case and a PITA because
they really do like to live in one directory.  Nevertheless that can
be dealt with in a number of ways (I think XEmacs implements three,
none of them particularly attractive).

Ulrich mentioned FHS.  Well, I haven't read the FHS carefully in a
decade, but IIRC from back then, the FHS does not in any way rule out
such "opaque packages".  If you want your package resources to be
available via system facilities (and for man pages and info files you
certainly do, thus the exception just mentioned), then indeed you want
to follow FHS.  But internal resources (including build-time-only
resources) can go anywhere you want.

There are disadvantages to "opaque packages".  It can take a lot more
stats to find stuff if you have a very flexible path search algorithm
such as kpathsea, which slows things quite a bit.  On those occasions
you do want to break the veil, what you see inside the package may be
neither pretty nor convenient.  But by the same token they tend to
increase cohesion and decrease coupling, which are usually considered
design goals.

You don't have to like this approach; I'm just saying it's one way to
look at ELPA packages that helps to rationalize them and emphasize
their benefits.

Re: BBDB v3 approaching release

[Stephen J. Turnbull]

Stephen J. Turnbull writes:
 > Roland Winkler writes:

 >  > Normally the user directory where bbdb-print creates its TeX file is
 >  > not (should not be!) the directory where BBDB keeps its TeX include
 >  > files.
 > 
 > That's one good way to do it, but not necessarily normal.

Ah, I didn't know what bbdb-print does.

Now that I do, I don't see what's so hard about

(shell-command (format "TEXINPUTS=%s%s tex %s"
                       (bbdb-style-file-directory)
                       (getenv "TEXINPUTS")
                       file-to-tex))

where 

(defcustom bbdb-style-file-directory nil)

(defun bbdb-style-file-directory ()
  (or bbdb-style-file-directory
      (setq bbdb-style-file-directory
            (file-name-directory (locate-library "bbdb")))))

Re: BBDB v3 approaching release

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Date: Fri, 31 May 2013 02:55:49 +0900
> 
> Ah, I didn't know what bbdb-print does.
> 
> Now that I do, I don't see what's so hard about
> 
> (shell-command (format "TEXINPUTS=%s%s tex %s"
>                        (bbdb-style-file-directory)
>                        (getenv "TEXINPUTS")
>                        file-to-tex))

That it only works with a Posixy shell?

Re: BBDB v3 approaching release

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: "Stephen J. Turnbull" <stephen@xemacs.org>
>> Date: Fri, 31 May 2013 02:55:49 +0900
>> 
>> Ah, I didn't know what bbdb-print does.
>> 
>> Now that I do, I don't see what's so hard about
>> 
>> (shell-command (format "TEXINPUTS=%s%s tex %s"
>>                        (bbdb-style-file-directory)
>>                        (getenv "TEXINPUTS")
>>                        file-to-tex))
>
> That it only works with a Posixy shell?

So modify process-environment.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: BBDB v3 approaching release

[Stephen J. Turnbull]

Eli Zaretskii writes:
 > > From: "Stephen J. Turnbull" <stephen@xemacs.org>
 > > Date: Fri, 31 May 2013 02:55:49 +0900
 > > 
 > > Ah, I didn't know what bbdb-print does.
 > > 
 > > Now that I do, I don't see what's so hard about
 > > 
 > > (shell-command (format "TEXINPUTS=%s%s tex %s"
 > >                        (bbdb-style-file-directory)
 > >                        (getenv "TEXINPUTS")
 > >                        file-to-tex))
 > 
 > That it only works with a Posixy shell?

Last I heard Emacs doesn't have a policy that says that's a
showstopper, although it won't stop you from fixing it if you like.
Anyway, I'm sure there's a way to work around it with enough effort.
I'm just not going to make it.  The code above is proof of concept,
not a patch submission to Emacs (or BBDB for that matter).

The practical deal-breaker for "install in the right place" is that
Emacs doesn't "own" the texmf hierarchies, so you can't guarantee that
ELPA can install those sources "where they belong" according to
tradition or FHS.  Given that, I don't see why anybody should care
where they are installed, as long as BBDB can find them.

Ted Z's proposal for enhancing ELPA packages' ability to find their
stuff is a first step in the right direction, I think.  But AFAIK
there is no spec for *user* FHS.  Python has been playing around with
~/.local among others (I think that may be an fd.o draft standard or
something?)  If that were to become widespread, you could add ~/.local
to your kpathsea path, and that would be a big win.  Failing that (ie,
for the foreseeable future), I think what ELPA should do is provide a
suite of functions for finding package resources such as elisp
(installed), the source tree, graphics and other multimedia, helper
files for external apps (eg, the bbdb-print TeX style files), helper
executables, and so on.

Re: BBDB v3 approaching release

[Tom Tromey]

>>>>> "Stephen" == Stephen J Turnbull <stephen@xemacs.org> writes:

Stephen> Failing that (ie, for the foreseeable future), I think what
Stephen> ELPA should do is provide a suite of functions for finding
Stephen> package resources such as elisp (installed), the source tree,
Stephen> graphics and other multimedia, helper files for external apps
Stephen> (eg, the bbdb-print TeX style files), helper executables, and
Stephen> so on.

It does already.  See (info "(elisp) Multi-file Packages"):

       If the multi-file package contains auxiliary data files (such as
    images), the package's Lisp code can refer to these files via the
    variable `load-file-name' (*note Loading::).  Here is an example:

         (defconst superfrobnicator-base (file-name-directory load-file-name))

         (defun superfrobnicator-fetch-image (file)
           (expand-file-name file superfrobnicator-base))

Tom

Re: BBDB v3 approaching release

[Stephen J. Turnbull]

Tom Tromey writes:
 > >>>>> "Stephen" == Stephen J Turnbull <stephen@xemacs.org> writes:

 > Stephen> Failing that (ie, for the foreseeable future), I think what
 > Stephen> ELPA should do is provide a suite of functions for finding
 > Stephen> package resources[...].
 > 
 > It does already.  See [load-file-name].

That assumes that everything is placed in a particular directory, or
perhaps in a fixed relative location to that directory.  What I have
in mind is something that supports more complex (and presumably
prettier) package organizations, so that you can do

    (locate-data-file 'my-package "sjt-face.png")

and things like that without assuming that images live in the same
directory as the Lisp code.

Re: BBDB v3 approaching release

[Ted Zlatanov]

On Fri, 31 May 2013 12:50:51 +0900 "Stephen J. Turnbull" <stephen@xemacs.org> wrote: 

SJT> Ted Z's proposal for enhancing ELPA packages' ability to find their
SJT> stuff is a first step in the right direction, I think.

Sorry, I don't know what I proposed :)

SJT> But AFAIK there is no spec for *user* FHS.

Besides ELPA, don't forget el-get.  It has its own directory structure
by necessity.  I don't see a problem with innovation at the user
directory level, as long as it doesn't leak into the system software.

SJT> I think what ELPA should do is provide a suite of functions for
SJT> finding package resources such as elisp (installed), the source
SJT> tree, graphics and other multimedia, helper files for external apps
SJT> (eg, the bbdb-print TeX style files), helper executables, and so
SJT> on.

The data link between Emacs and the OS and other software installed
within is pretty fragile so I don't think this is an easy integration
task.  Internally to Emacs it's no problem of course.  I think the
answer is to reduce dependency on external tools.  Emacs can do most
things on its own; `bbdb-print' is a very unusual case.

Ted

Re: BBDB v3 approaching release

[Ulrich Mueller]

>>>>> On Wed, 29 May 2013, Stefan Monnier wrote:

>> How do I configure install locations of a package if it's in ELPA
>> format?

> You don't.

Why is this better than having them configurable? Especially, why are
you asking that a package like BBDB that has a perfectly working
autoconf build system should _remove_ it?

>> Especially, if the package has non-lisp components?

> You leave them alongside the Elisp files.

Emacs itself uses a different layout and keeps non-lisp files in
different directories like etc or info. (Hopefully there are no plans
to change that?)

For example, for Info files it's really a PITA if they're not
collected in one (or at least, few) central locations.

> And when you need them, your Elisp package will find them by looking
> around itself (it can get access to its own location via
> `load-file-name').

This means that anyone who wants to adhere to some standard like FHS
must move files around manually. I had to do this way too often when
packaging things for Gentoo.

Most packages are at least friendly enough and spend a defvar or
defcustom that allows to configure these directories (often with a
fallback to the above-mentioned load-file-name location).

Ulrich

Re: BBDB v3 approaching release

[Roland Winkler]

On Thu May 30 2013 Ulrich Mueller wrote:
> Emacs itself uses a different layout and keeps non-lisp files in
> different directories like etc or info. (Hopefully there are no plans
> to change that?)

The problem is really that the TeX files generated by bbdb-print
connect two different worlds:

The TeX file is generated by emacs that comes with its search path
and installation tree. But then this TeX file gets compiled by the
TeX command that only knows its own search paths.

And all this happens in a user directory so that everything should
not depend on the absolute directories used by the particular
installations of emacs and TeX.

Re: BBDB v3 approaching release

[Ulrich Mueller]

>>>>> On Thu, 30 May 2013, Roland Winkler wrote:

> The problem is really that the TeX files generated by bbdb-print
> connect two different worlds:

Sure, these are the more interesting cases. Other such examples
include AUCTeX, SLIME, and Pymacs. Installation is trivial if a
package consists of elisp files only.

> The TeX file is generated by emacs that comes with its search path
> and installation tree. But then this TeX file gets compiled by the
> TeX command that only knows its own search paths.

> And all this happens in a user directory so that everything should
> not depend on the absolute directories used by the particular
> installations of emacs and TeX.

That's why there are distros that set up things such that different
pieces of software fit together, and work for the user out of the box.
Of course, it will help if the package is configurable and can adapt
to different environments.

Ulrich

Re: BBDB v3 approaching release

[Ted Zlatanov]

On Thu, 30 May 2013 13:24:48 +0200 "Roland Winkler" <winkler@gnu.org> wrote: 

RW> On Thu May 30 2013 Ulrich Mueller wrote:
>> Emacs itself uses a different layout and keeps non-lisp files in
>> different directories like etc or info. (Hopefully there are no plans
>> to change that?)

RW> The problem is really that the TeX files generated by bbdb-print
RW> connect two different worlds:

RW> The TeX file is generated by emacs that comes with its search path
RW> and installation tree. But then this TeX file gets compiled by the
RW> TeX command that only knows its own search paths.

RW> And all this happens in a user directory so that everything should
RW> not depend on the absolute directories used by the particular
RW> installations of emacs and TeX.

This may be quite heretical, but have you considered Markdown for the
BBDB docs?  No build systems needed; readable as plain text; convertible
to many other formats with little work; really easy to learn and use.
Emacs can view it.  I've been happy with Markdown for personal and work
use.

The lack of a build system is especially appealing, from experience with
installing hundreds of megabytes for the documentation support toolchain
for Gnus and BBDB.

Ted

Re: BBDB v3 approaching release

[Stefan Monnier]

> This may be quite heretical, but have you considered Markdown for the
> BBDB docs?

bbdb-print doesn't have anything to do with documentation.
It's a function that lets you print your bbdb addressbook via LaTeX.


        Stefan

Re: BBDB v3 approaching release

[Ted Zlatanov]

On Thu, 30 May 2013 13:11:56 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>> This may be quite heretical, but have you considered Markdown for the
>> BBDB docs?

SM> bbdb-print doesn't have anything to do with documentation.
SM> It's a function that lets you print your bbdb addressbook via LaTeX.

D'oh, sorry.

Ted

Re: BBDB v3 approaching release

[Stefan Monnier]

>>> How do I configure install locations of a package if it's in ELPA
>>> format?
>> You don't.
> Why is this better than having them configurable?

Because that saves you from having to configure it.

> Especially, why are you asking that a package like BBDB that has
> a perfectly working autoconf build system should _remove_ it?

I didn't ask to remove it: it can be kept in the ELPA package.
It's just not useful/needed for the usual ELPA style of
distribution/installation.

>>> Especially, if the package has non-lisp components?
>> You leave them alongside the Elisp files.
> Emacs itself uses a different layout and keeps non-lisp files in
> different directories like etc or info.

Indeed.  In some cases it was a good choice, in others I'm not so sure.

> (Hopefully there are no plans to change that?)

It's definitely not important enough to waste time changing it unless
there's a good reason for it.

> For example, for Info files it's really a PITA if they're not
> collected in one (or at least, few) central locations.

Why?

>> And when you need them, your Elisp package will find them by looking
>> around itself (it can get access to its own location via
>> `load-file-name').
> This means that anyone who wants to adhere to some standard like FHS
> must move files around manually. I had to do this way too often when
> packaging things for Gentoo.

I don't see any particular reason why you'd feel compelled to break an
ELPA package into its constituents and spread them around in different
directories, just for the sake of following some standard.

If there's a real benefit to it and it's higher than the cost of moving
things around, then by all means go for it.  But "the ELPA way" is
pretty damn convenient and I personally can't think of any benefit you'd
get from applying the FHS to it.

> Most packages are at least friendly enough and spend a defvar or
> defcustom that allows to configure these directories (often with a
> fallback to the above-mentioned load-file-name location).

In order to be able to use load-file-name, you need to evaluate it
during load and save it in some global variable.  So, yes, a natural way
to do it ends up introducing defvar/defcustoms for that anyway.


        Stefan

Re: BBDB v3 approaching release

[Ted Zlatanov]

On Thu, 30 May 2013 11:37:13 +0200 Ulrich Mueller <ulm@gentoo.org> wrote: 

>>>>>> On Wed, 29 May 2013, Stefan Monnier wrote:
>>> How do I configure install locations of a package if it's in ELPA
>>> format?

>> You don't.

UM> Why is this better than having them configurable? Especially, why are
UM> you asking that a package like BBDB that has a perfectly working
UM> autoconf build system should _remove_ it?

I don't think Stefan asked for that.  Simply, when something is
installed as an ELPA package, it doesn't have control over its install
location.

UM> This means that anyone who wants to adhere to some standard like FHS
UM> must move files around manually. I had to do this way too often when
UM> packaging things for Gentoo.

UM> Most packages are at least friendly enough and spend a defvar or
UM> defcustom that allows to configure these directories (often with a
UM> fallback to the above-mentioned load-file-name location).

Installing system packages and installing user packages are completely
different things.  The ELPA is intended as a user-accessible format,
where "user" could be "root".  But it doesn't have deep integration with
any of the Emacs platforms, nor was that part of its design.  I think
that's worth discussing further and improving.

Ted

Re: BBDB v3 approaching release

[Steinar Bang]

>>>>> Ulrich Mueller <ulm@gentoo.org>:
>>>>> On Tue, 28 May 2013, Stefan Monnier wrote:

>> You *really* want to stick to the ELPA format. It's simple and
>> straightforward for you, and for the end-users.

> How do I configure install locations of a package if it's in ELPA
> format? Especially, if the package has non-lisp components?

Just FYI: someone already seems to have done the ELPA bit, because
snapshots of the new BBDB is available in MELPA:
 http://www.emacswiki.org/emacs/ELPA
 http://www.emacswiki.org/emacs/MELPA
 http://melpa.milkbox.net/

The BBDB snapshot I installed from MELPA yesterday, has the version
number 20130526.1945.