[ELPA] Package proposal: EBDB

[ELPA] Package proposal: EBDB

[Eric Abrahamsen]

Hi all,

I'd like to propose the following package for inclusion in ELPA:
https://github.com/girzel/ebdb

It's a port/re-write of BBDB using the EIEIO libraries.

Perhaps apropos of the recent copyright discussions: there's a fair
bit of BBDB code still in there. I haven't gone through and measured,
but my top-of-the-head guess is around 15-20%. I've noted this fact in
the comments sections of the files, including the names of original
authors where applicable. I was trying to be polite, but besides the
etiquette question I suppose there might be a copyright issue here.

Can anyone advise? I'd be happy to go through and figure out exactly
how much (and which parts) of the code is original to BBDB, if that's
relevant.

My other question is: if I require the cl-generic package for
backwards compatibility, what's the earliest Emacs version I can
expect to be compatible with? I'm also using seq 2.0 and pcase, and
seq at least says it wants Emacs 25.1 or up, so I guess that's my
floor, regardless...

Thanks,
Eric

Re: [ELPA] Package proposal: EBDB

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Perhaps apropos of the recent copyright discussions: there's a fair
  > bit of BBDB code still in there. I haven't gone through and measured,
  > but my top-of-the-head guess is around 15-20%. I've noted this fact in
  > the comments sections of the files, including the names of original
  > authors where applicable.

Alas, this does raise a copyright issue.  To include this in Emacs, we
need to get legal papers from all the contributors of code that is
still in your version (including you).  With the exception of anyone
whose contributions to Emacs (including this package) will be minimal
(under 10 lines or so).

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: [ELPA] Package proposal: EBDB

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Sun, 30 Jul 2017 20:49:56 -0400
> Cc: emacs-devel@gnu.org
> 
> Alas, this does raise a copyright issue.  To include this in Emacs, we
> need to get legal papers from all the contributors of code that is
> still in your version (including you).  With the exception of anyone
> whose contributions to Emacs (including this package) will be minimal
> (under 10 lines or so).

Another exceptions is people who already have a copyright assignment
on file for Emacs.

Re: [ELPA] Package proposal: EBDB

[Eric Abrahamsen]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > Perhaps apropos of the recent copyright discussions: there's a fair
>   > bit of BBDB code still in there. I haven't gone through and measured,
>   > but my top-of-the-head guess is around 15-20%. I've noted this fact in
>   > the comments sections of the files, including the names of original
>   > authors where applicable.
>
> Alas, this does raise a copyright issue.  To include this in Emacs, we
> need to get legal papers from all the contributors of code that is
> still in your version (including you).  With the exception of anyone
> whose contributions to Emacs (including this package) will be minimal
> (under 10 lines or so).

Okay, I guess that's not a surprise. I'll figure out which code was
likely written by whom, and come up with a list of names. If I raise
them here, can someone help me check if they've got assignment?

As Eli mentions, I bet many of them (including myself) have already
signed the papers.

Eric

Re: [ELPA] Package proposal: EBDB

[Eli Zaretskii]

> From: Eric Abrahamsen <eric@ericabrahamsen.net>
> Date: Sun, 30 Jul 2017 20:12:51 -0700
> 
> As Eli mentions, I bet many of them (including myself) have already
> signed the papers.

You can ask me to check about specific names, if you want.

Re: [ELPA] Package proposal: EBDB

[Eric Abrahamsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Eric Abrahamsen <eric@ericabrahamsen.net>
>> Date: Sun, 30 Jul 2017 20:12:51 -0700
>> 
>> As Eli mentions, I bet many of them (including myself) have already
>> signed the papers.
>
> You can ask me to check about specific names, if you want.

Thanks, I'll do that.

Re: [ELPA] Package proposal: EBDB

[John Wiegley]

>>>>> "EA" == Eric Abrahamsen <eric@ericabrahamsen.net> writes:

EA> It's a port/re-write of BBDB using the EIEIO libraries.

Can you explain the benefit of including this work into Emacs?  Specifically,
does it solve problems being encountered with the current BBDB, or does it
pave the way for new work?

Thanks,
-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: [ELPA] Package proposal: EBDB

[Stefan Monnier]

> It's a port/re-write of BBDB using the EIEIO libraries.
> Perhaps apropos of the recent copyright discussions: there's a fair
> bit of BBDB code still in there.

BTW, which BBDB are we talking about, here.
Is it the BBDB v2, or BBDB v3?


        Stefan "presuming v3"

Re: [ELPA] Package proposal: EBDB

[Eric Abrahamsen]

John Wiegley <jwiegley@gmail.com> writes:

>>>>>> "EA" == Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
> EA> It's a port/re-write of BBDB using the EIEIO libraries.
>
> Can you explain the benefit of including this work into Emacs?  Specifically,
> does it solve problems being encountered with the current BBDB, or does it
> pave the way for new work?

It was originally meant to be a set of patches to BBDB, but snowballed
from there. My feeling was that the original package was inflexible, and
very difficult to extend. EBDB is made to be extensible: multiple
databases, an internationalization mechanism, hooks for integration into
other packages, subclassable records and fields that can have arbitrary
behavior... The code as it stands offers a few solid benefits over BBDB,
but most importantly there's a lot of room for building on top of it.
The class/generic method approach means that other packages could add
all kinds of new behavior to EBDB simply by being loaded.

Probably some of it did end up being new code for new code's sake...

I wasn't thinking of ELPA as "inclusion into Emacs", but maybe that's
what it is?

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> It's a port/re-write of BBDB using the EIEIO libraries.
>> Perhaps apropos of the recent copyright discussions: there's a fair
>> bit of BBDB code still in there.
>
> BTW, which BBDB are we talking about, here.
> Is it the BBDB v2, or BBDB v3?
>
>
>         Stefan "presuming v3"

Yup, I started out with version 3.

Eric

Re: [ELPA] Package proposal: EBDB

[John Wiegley]

>>>>> "EA" == Eric Abrahamsen <eric@ericabrahamsen.net> writes:

EA> I wasn't thinking of ELPA as "inclusion into Emacs", but maybe that's what
EA> it is?

Yes, that's what certainly it's intended to be/mean, from my point of view.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: [ELPA] Package proposal: EBDB

[Eric Abrahamsen]

John Wiegley <jwiegley@gmail.com> writes:

>>>>>> "EA" == Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
> EA> I wasn't thinking of ELPA as "inclusion into Emacs", but maybe that's what
> EA> it is?
>
> Yes, that's what certainly it's intended to be/mean, from my point of view.

Good to know.

I guess my arguments for the package are pretty much what I stated
earlier, then. The present BBDB is limited in that record fields are
just key-value pairs, for the most part strings. If you want to add a
new type of field, you need to add branches to about a dozen `cond'
statements throughout the BBDB codebase. In EBDB, new field types can be
added via an external library. Likewise, the behavior of existing fields
(and records and databases) can be altered with external libraries. EBDB
fields can have arbitrarily complex data slots and behavior.

Records can be of different types. People and organizations are built
in, other record types can be added. Databases are likewise
subclass-able.

I think EBDB's internationalization framework is important. BBDB is
fairly US-centric. EBDB can provide very fine-grained behavior for
phones, addresses and names from various countries/locales/scripts. I
have so far only scratched my own itch, with a China-specific library,
but all the hooks are there.

At present EBDB has some advantages (like multiple databases, record
UUIDs, multiple buffers) that could be added to BBDB as well. But I
think the points above are things that could not be reasonably added to
BBDB as it stands: that was the point of the rewrite.

Eric

Re: [ELPA] Package proposal: EBDB

[John Wiegley]

>>>>> "EA" == Eric Abrahamsen <eric@ericabrahamsen.net> writes:

EA> I guess my arguments for the package are pretty much what I stated
EA> earlier, then. The present BBDB is limited in that record fields are just
EA> key-value pairs, for the most part strings. If you want to add a new type
EA> of field, you need to add branches to about a dozen `cond' statements
EA> throughout the BBDB codebase. In EBDB, new field types can be added via an
EA> external library. Likewise, the behavior of existing fields (and records
EA> and databases) can be altered with external libraries. EBDB fields can
EA> have arbitrarily complex data slots and behavior.

This paragraph is enough for me to want it. :) The ability to make BBDB
extensible in future without requiring core changes is definitely a positive
thing.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: [ELPA] Package proposal: EBDB

[Eric Abrahamsen]

John Wiegley <jwiegley@gmail.com> writes:

>>>>>> "EA" == Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
> EA> I guess my arguments for the package are pretty much what I stated
> EA> earlier, then. The present BBDB is limited in that record fields are just
> EA> key-value pairs, for the most part strings. If you want to add a new type
> EA> of field, you need to add branches to about a dozen `cond' statements
> EA> throughout the BBDB codebase. In EBDB, new field types can be added via an
> EA> external library. Likewise, the behavior of existing fields (and records
> EA> and databases) can be altered with external libraries. EBDB fields can
> EA> have arbitrarily complex data slots and behavior.
>
> This paragraph is enough for me to want it. :) The ability to make BBDB
> extensible in future without requiring core changes is definitely a positive
> thing.

Well, good! I'm bad at pitching, but I wouldn't have put all this work
in if I didn't think it was a fundamental improvement. The goal is a
fairly tight core of code that doesn't need to know about the
particulars of various database, record and field classes.

I'll continue sorting out the copyright questions.

Thanks,
Eric

Re: [ELPA] Package proposal: EBDB

[Roland Winkler]

> The ability to make BBDB extensible in future without requiring
> core changes is definitely a positive thing.

I agree, using, e.g., country-specific libraries can be a great way
of extending EBDB.  But this can also cause problems:

- Writing country-specific libraries for EBDB can be a fair bit of
  work.  Someone may develop a library for country XYZ up to the
  point "it works for me".  With the complexity of EBDB the
  developer may not notice / not care that some "irrelevant"
  features do not work.  When other users want to use the library,
  they can be stuck.

- Yet worse: "plain" users may have some records from country XYZ in
  their database, using the EBDB library for XYZ.  At some point,
  the very core of the EBDB code base may get updated in a way that
  also requires an update of the country-specific EBDB libraries.
  But the maintainer of the XYZ library may have disappeared from
  the stage for whatever reason.  What can the users do?  The EBDB
  database of a user might become unusable if its XYZ part cannot be
  read anymore.

  The opposite is also possible: It may turn out that it would be
  nice to update the EBDB code base in a way that also requires an
  update of the EBDB country-specific "add-on libraries" (or any
  other add-on libraries handling certain new fields for EBDB).  If
  there are many such country-specific add-on libraries out in the
  wild, it may become difficult to update the EBDB code base without
  breaking EBDB for many users.

  (Having developed BBDB for some time, I find it hard to predict
  when the code base of BBDB may have reached a level of maturity
  that allowed me to exclude the possibility of any further
  upgrades, say, in the format of the BBDB database files.  Then I
  am glad that such updates of BBDB can include the code to migrate
  the BBDB database files of the users.)

  (BBDB allows the user to customize the handling of addresses in a
  country-specific way; but this does not affect what is being
  stored in the database file using a universal, country-independent
  format.)

- In the worst case, also legal problems may arise: it may not be
  possible that someone else updates the code for the XYZ library.
  (But I am not a lawyer who could predict the details of such
  scenarios.)

I guess that to some extent these are generic aspects of an
object-oriented programming model, which is something I am less
familiar with in such a context.  Maybe others can comment.

It is certainly a [EB]BDB-specific issue that any code development
needs to keep in mind that many users already bring along their
database files.

Re: [ELPA] Package proposal: EBDB

[Eric Abrahamsen]

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

>> The ability to make BBDB extensible in future without requiring
>> core changes is definitely a positive thing.
>
> I agree, using, e.g., country-specific libraries can be a great way
> of extending EBDB.  But this can also cause problems:

All of these are very valid points. A couple of responses below.

> - Writing country-specific libraries for EBDB can be a fair bit of
>   work.  Someone may develop a library for country XYZ up to the
>   point "it works for me".  With the complexity of EBDB the
>   developer may not notice / not care that some "irrelevant"
>   features do not work.  When other users want to use the library,
>   they can be stuck.
>
> - Yet worse: "plain" users may have some records from country XYZ in
>   their database, using the EBDB library for XYZ.  At some point,
>   the very core of the EBDB code base may get updated in a way that
>   also requires an update of the country-specific EBDB libraries.
>   But the maintainer of the XYZ library may have disappeared from
>   the stage for whatever reason.  What can the users do?  The EBDB
>   database of a user might become unusable if its XYZ part cannot be
>   read anymore.
>
>   The opposite is also possible: It may turn out that it would be
>   nice to update the EBDB code base in a way that also requires an
>   update of the EBDB country-specific "add-on libraries" (or any
>   other add-on libraries handling certain new fields for EBDB).  If
>   there are many such country-specific add-on libraries out in the
>   wild, it may become difficult to update the EBDB code base without
>   breaking EBDB for many users.
>
>   (Having developed BBDB for some time, I find it hard to predict
>   when the code base of BBDB may have reached a level of maturity
>   that allowed me to exclude the possibility of any further
>   upgrades, say, in the format of the BBDB database files.  Then I
>   am glad that such updates of BBDB can include the code to migrate
>   the BBDB database files of the users.)
>
>   (BBDB allows the user to customize the handling of addresses in a
>   country-specific way; but this does not affect what is being
>   stored in the database file using a universal, country-independent
>   format.)

EBDB's internationalization framework doesn't alter data structures in
any way -- that was a basic principle. It only affects methods that
read, parse and display field data. In the (likely) event that a country
library gets out of step with the main codebase, errors may occur, but
all a user would have to do is unload the problematic library.

> - In the worst case, also legal problems may arise: it may not be
>   possible that someone else updates the code for the XYZ library.
>   (But I am not a lawyer who could predict the details of such
>   scenarios.)

My idea was to ask that internationalization libraries live in ELPA
(I've been talking to Feng Shu, who contributed to the China library,
about this issue). The recent copyright discussions on this list have
touched on Emacs maintainers' ability to push to ELPA packages when
necessary, and I think this is a perfect example. If a country library
is suddenly abandoned, someone with ELPA access could do some emergency
surgery to at least stop errors.

Of course, you can't stop people pushing packages to Melpa, but control
is only possible up to a point.

The stability of the data structures and API is another question, one I
was planning to think about once the number of EBDB users hit the double
digits :)

> I guess that to some extent these are generic aspects of an
> object-oriented programming model, which is something I am less
> familiar with in such a context.  Maybe others can comment.

I've become very, very aware of the pitfalls of [e]lisp's OO model while
working on this package. Generic methods are essentially cond branches
that don't have to live within the cond statement. That's awesome
because cond branches can be defined anywhere. It's a nightmare
because... cond branches can be defined anywhere. It's magic, with both
the positive and negative implications of "magic".

Eric

Re: [ELPA] Package proposal: EBDB

[Eric Abrahamsen]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > Perhaps apropos of the recent copyright discussions: there's a fair
>   > bit of BBDB code still in there. I haven't gone through and measured,
>   > but my top-of-the-head guess is around 15-20%. I've noted this fact in
>   > the comments sections of the files, including the names of original
>   > authors where applicable.
>
> Alas, this does raise a copyright issue.  To include this in Emacs, we
> need to get legal papers from all the contributors of code that is
> still in your version (including you).  With the exception of anyone
> whose contributions to Emacs (including this package) will be minimal
> (under 10 lines or so).

Okay, I think I've sorted everything out except for one chunk of one
file, where I haven't yet been able to contact the author. I think I
might just take that chunk out for now, and get the package moving. Just
for background, Roland reminded me of this prior related discussion:

https://lists.gnu.org/archive/html/emacs-devel/2015-11/msg01888.html

I think I've cleared everything but that one chunk of ebdb-gnus.

If that's okay, I'll do a few more compiler-warning cleanups, and add
the package as an external.

Thanks,
Eric

Re: [ELPA] Package proposal: EBDB

[Eric Abrahamsen]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Richard Stallman <rms@gnu.org> writes:
>
>> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
>> [[[ whether defending the US Constitution against all enemies,     ]]]
>> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>>
>>   > Perhaps apropos of the recent copyright discussions: there's a fair
>>   > bit of BBDB code still in there. I haven't gone through and measured,
>>   > but my top-of-the-head guess is around 15-20%. I've noted this fact in
>>   > the comments sections of the files, including the names of original
>>   > authors where applicable.
>>
>> Alas, this does raise a copyright issue.  To include this in Emacs, we
>> need to get legal papers from all the contributors of code that is
>> still in your version (including you).  With the exception of anyone
>> whose contributions to Emacs (including this package) will be minimal
>> (under 10 lines or so).
>
> Okay, I think I've sorted everything out except for one chunk of one
> file, where I haven't yet been able to contact the author. I think I
> might just take that chunk out for now, and get the package moving. Just
> for background, Roland reminded me of this prior related discussion:
>
> https://lists.gnu.org/archive/html/emacs-devel/2015-11/msg01888.html
>
> I think I've cleared everything but that one chunk of ebdb-gnus.
>
> If that's okay, I'll do a few more compiler-warning cleanups, and add
> the package as an external.

Okay, I give up: how do you add an external package?

We add the appropriate line to externals-list in the master branch,
right? Then push that? Then create a new branch, in my case
external/ebdb, and put what in it -- anything? Will something
automatically happen if I push that branch to ELPA?

Thanks
Eric

Re: [ELPA] Package proposal: EBDB

[Stefan Monnier]

> We add the appropriate line to externals-list in the master branch,
> right?  Then push that? Then create a new branch, in my case
> external/ebdb,

First create (and populate) the externals/ebdb branch.  Only once
that is done can you update the externals-list file to point to it.

> and put what in it -- anything?

Pretty much, except:
- .el files in the top-level directory.
- the metadata in the <pkg>.el file (in your case, ebdb.el).

> Will something automatically happen if I push that branch to ELPA?

No, it will happen when you push the change to externals-list.


        Stefan

Re: [ELPA] Package proposal: EBDB

[Eric Abrahamsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> We add the appropriate line to externals-list in the master branch,
>> right?  Then push that? Then create a new branch, in my case
>> external/ebdb,
>
> First create (and populate) the externals/ebdb branch.  Only once
> that is done can you update the externals-list file to point to it.

Okay, this is what I was confused about. I have to populate the branch
with the code from the existing github repo, obviously I'm not just
copying files in there, I need to clone the repo into it somehow. The
README says:

git clone --reference .. --single-branch --branch externals/PACKAGE $(git config remote.origin.url) PACKAGE

Though I can't tell from the README if that's meant to be the command to
add an external to ELPA, or just pull down an existing external and look
at it. Anyway, running that command just gets me:

Could not find remote branch externals/ebdb to clone

Which is no surprise.

How do I populate the branch?

Eric

Re: [ELPA] Package proposal: EBDB

[Stefan Monnier]

> Okay, this is what I was confused about. I have to populate the branch
> with the code from the existing github repo, obviously I'm not just
> copying files in there, I need to clone the repo into it somehow. The
> README says:

> git clone --reference .. --single-branch --branch externals/PACKAGE $(git
> config remote.origin.url) PACKAGE

> Though I can't tell from the README if that's meant to be the command to
> add an external to ELPA, or just pull down an existing external and look
> at it. Anyway, running that command just gets me:

"git clone" doesn't modify any existing repository, so that can't be the
command that adds a branch to a repository.

> How do I populate the branch?

IIRC it's something like

    git push gnuelpa master:externals/ebdb

assuming you've configured your local clone of ebdb with something like

    git remote add gnuelpa <user>@git.sv.gnu.org:/srv/git/emacs/elpa.git


-- Stefan

Re: [ELPA] Package proposal: EBDB

[Eric Abrahamsen]

[-- Attachment #1: Type: text/plain, Size: 1197 bytes --]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Okay, this is what I was confused about. I have to populate the branch
>> with the code from the existing github repo, obviously I'm not just
>> copying files in there, I need to clone the repo into it somehow. The
>> README says:
>
>> git clone --reference .. --single-branch --branch externals/PACKAGE $(git
>> config remote.origin.url) PACKAGE
>
>> Though I can't tell from the README if that's meant to be the command to
>> add an external to ELPA, or just pull down an existing external and look
>> at it. Anyway, running that command just gets me:
>
> "git clone" doesn't modify any existing repository, so that can't be the
> command that adds a branch to a repository.
>
>> How do I populate the branch?
>
> IIRC it's something like
>
>     git push gnuelpa master:externals/ebdb
>
> assuming you've configured your local clone of ebdb with something like
>
>     git remote add gnuelpa <user>@git.sv.gnu.org:/srv/git/emacs/elpa.git

Aha! Thank you, that's what I was missing. It seems to have worked, I
guess I'll know for sure when the package gets built.

Assuming all goes well, can I push this documentation patch to ELPA?

Eric


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Add-explicit-instructions-for-new-external-packages.patch --]
[-- Type: text/x-diff, Size: 1098 bytes --]

From b33289dab83b5f5abe93e4385d322fbfe36a1b27 Mon Sep 17 00:00:00 2001
From: Eric Abrahamsen <eric@ericabrahamsen.net>
Date: Mon, 14 Aug 2017 08:56:11 -0700
Subject: [PATCH] Add explicit instructions for new external packages

* README: Spell out the process for new external packages.
---
 README | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/README b/README
index 322392997..48c105994 100644
--- a/README
+++ b/README
@@ -194,6 +194,15 @@ help and only gets in the way.
 In the `external' case, the copy of the code is not kept here but in the
 `externals/<pkg-name>' branch in the `elpa' repository.
 
+To add a new externals package, first add this `elpa' repository as a
+new remote in your existing repository.  Then push a local branch to a
+new remote branch in `elpa', named externals/<pkgname>.  For example:
+
+   git push elpa master:externals/<pkgname>
+
+Then edit the `externals-list' file as mentioned above, and push that
+change to `elpa's master branch.
+
 You can check out all the external packages into the `packages' directory
 with the command:
 
-- 
2.14.1

Re: [ELPA] Package proposal: EBDB

[Stefan Monnier]

> Aha! Thank you, that's what I was missing. It seems to have worked, I
> guess I'll know for sure when the package gets built.

I just noticed the following issues:
- You use oset-default on instance fields.  This used to work in earlier
  EIEIO and still mostly work now thanks to a hack, but it creates
  a weird/adhoc semantics in terms of interaction with the :initform, so
  I'd like to get rid of this backward compatibility.
- ebdb-vm and ebdb-mu4e will break the compilation of the package if the
  user doesn't have VM and mu4e installed.

The appended patch tries to fix those two, but please take a look at it
to make sure it still works correctly (especially the ebdb-vm part is
quick&dirty, leaving a lot of warnings when VM is not installed, some
of them may be real bugs).

> Assuming all goes well, can I push this documentation patch to ELPA?

Yes, please do, thank you,


        Stefan


diff --git a/.gitignore b/.gitignore
new file mode 100644
index 000000000..f56da6eb7
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,4 @@
+*.elc
+ebdb-autoloads.el
+ebdb-pkg.el
+
diff --git a/ebdb-format.el b/ebdb-format.el
index cd8ccc5ae..46726e15f 100644
--- a/ebdb-format.el
+++ b/ebdb-format.el
@@ -40,7 +40,8 @@
    (coding-system
     :type symbol
     :initarg :coding-system
-    :initform nil
+    ;; "`," is used to trick EIEIO into evaluating the form.
+    :initform `,buffer-file-coding-system
     :documentation "The coding system for the formatted
     file/buffer/stream.")
    ;; TODO: Provide for "psuedo field classes" like 'primary-mail and
@@ -93,8 +94,6 @@
   :documentation "Abstract base class for EBDB formatters.
   Subclass this to produce real formatters.")
 
-(eieio-oset-default 'ebdb-formatter 'coding-system buffer-file-coding-system)
-
 (cl-defmethod ebdb-string ((fmt ebdb-formatter))
   (slot-value fmt 'object-name))
 
diff --git a/ebdb-mu4e.el b/ebdb-mu4e.el
index 2e4ee5e20..8d0798391 100644
--- a/ebdb-mu4e.el
+++ b/ebdb-mu4e.el
@@ -25,9 +25,11 @@
 ;;; Code:
 
 (require 'ebdb-mua)
-(require 'mu4e-view)
+(if t (require 'mu4e-view)) ;;Dummy test to `require' only at runtime.
 
 ;; Tackle `mu4e-headers-mode' later
+(defvar mu4e~view-buffer-name)
+(defvar mu4e-view-mode-map)
 
 (cl-defmethod ebdb-mua-message-header ((header string)
 				   &context (major-mode mu4e-view-mode))
@@ -45,7 +47,7 @@
 
 ;; Why wasn't `ebdb-mua-auto-update' ever hooked in to mu4e?
 
-(add-hook 'mu4e-main-mode-hook 'ebdb-insinuate-mu4e)
+(add-hook 'mu4e-main-mode-hook #'ebdb-insinuate-mu4e)
 
 (provide 'ebdb-mu4e)
 ;;; ebdb-mu4e.el ends here
diff --git a/ebdb-vm.el b/ebdb-vm.el
index 27f5f4c69..00766e10b 100644
--- a/ebdb-vm.el
+++ b/ebdb-vm.el
@@ -25,6 +25,7 @@
 
 (require 'ebdb-com)
 (require 'ebdb-mua)
+(when t ;;Dummy test to `require' only at runtime.
 (require 'vm-autoloads)
 (require 'vm)
 (require 'vm-motion)
@@ -33,7 +34,7 @@
 (require 'vm-vars)
 (require 'vm-macro)
 (require 'vm-message)
-(require 'vm-misc)
+(require 'vm-misc))
 
 (defgroup ebdb-mua-vm nil
   "VM-specific EBDB customizations"
@@ -366,9 +367,11 @@ from different senders."
             ;; the EBDB record of the sender.
             (lambda (m) (ebdb-mua-summary-mark (vm-su-from m))))))
 
+;; FIXME: `vm' is required earlier, so (eval-after-load "vm" ...) doesn't make
+;; much sense at this point.
 (eval-after-load "vm" '(ebdb-insinuate-vm))
 
-(add-hook 'vm-select-message-hook 'ebdb-mua-auto-update)
+(add-hook 'vm-select-message-hook #'ebdb-mua-auto-update)
 
 (provide 'ebdb-vm)
 ;;; ebdb-vm.el ends here
diff --git a/ebdb.el b/ebdb.el
index 16af67494..1daaf8623 100644
--- a/ebdb.el
+++ b/ebdb.el
@@ -2056,11 +2056,11 @@ Eventually this method will go away."
 (defclass ebdb-field-image (ebdb-field)
   ((image
     :type (or null string symbol)
-    :initarg :image))
+    :initarg :image
+    ;; "`," is used to trick EIEIO into evaluating the form.
+    :initform `,ebdb-image))
   :human-readable "image")
 
-(eieio-oset-default 'ebdb-field-image 'image ebdb-image)
-
 (cl-defmethod ebdb-read ((image (subclass ebdb-field-image)) &optional slots obj)
   (let ((existing (when obj (slot-value obj 'image)))
 	value)
@@ -3378,7 +3378,8 @@ executable.  When a symbol, assume an Elisp function."
     ;; I don't think I can actually set this to `ebdb-record': the
     ;; type needs to be a class, not an instance.  Can I do that?
     :type symbol
-    :initform nil
+    ;; "`," is used to trick EIEIO into evaluating the form.
+    :initform `,ebdb-default-record-class
     :custom symbol
     :documentation
     "The default EIEIO class for records in this database.  Must
@@ -3389,11 +3390,6 @@ not be instantiated directly, subclass it instead."
   :allow-nil-initform t
   :abstract t)
 
-;; I was told not to use this in Gnus, but I don't remember why.  I
-;; suspect it was backward compatibility, and that's obviously already
-;; out the window.
-(oset-default 'ebdb-db record-class ebdb-default-record-class)
-
 (cl-defmethod initialize-instance ((db ebdb-db) &optional slots)
   "Make sure DB has a uuid."
   (unless (and (slot-boundp db 'uuid)

Re: [ELPA] Package proposal: EBDB

[Eric Abrahamsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Aha! Thank you, that's what I was missing. It seems to have worked, I
>> guess I'll know for sure when the package gets built.
>
> I just noticed the following issues:
> - You use oset-default on instance fields.  This used to work in earlier
>   EIEIO and still mostly work now thanks to a hack, but it creates
>   a weird/adhoc semantics in terms of interaction with the :initform, so
>   I'd like to get rid of this backward compatibility.

Huh, interesting. Is that function completely deprecated, or still
usable for class-allocated slots?

> - ebdb-vm and ebdb-mu4e will break the compilation of the package if the
>   user doesn't have VM and mu4e installed.
>
> The appended patch tries to fix those two, but please take a look at it
> to make sure it still works correctly (especially the ebdb-vm part is
> quick&dirty, leaving a lot of warnings when VM is not installed, some
> of them may be real bugs).

I thought about extracting those two into separate packages, and
probably should have done that. I pulled all the other libraries that
depended on non-core packages into their own separate packages, and I
don't know why I didn't do that for these two.

Actually, I do know: vm and mu4e aren't installable via the package
manager. If I make separate packages, and put a package-requires header
in them for vm and mu4e, will package.el be satisfied if a user has
installed them via other means? Or will it bark?

Another option would be a boatload of (autoload 'function "ext:vm")
statements.

I'll make your other changes, and maybe just pull ebdb-vm and ebdb-mu4e
for now, pending further thought.

>> Assuming all goes well, can I push this documentation patch to ELPA?
>
> Yes, please do, thank you,

Will do.

Thanks,
Eric

Re: [ELPA] Package proposal: EBDB

[Stefan Monnier]

> Huh, interesting.  Is that function completely deprecated, or still
> usable for class-allocated slots?

It's fine for class-allocated slots.

>> - ebdb-vm and ebdb-mu4e will break the compilation of the package if the
>> user doesn't have VM and mu4e installed.
>> The appended patch tries to fix those two, but please take a look at it
>> to make sure it still works correctly (especially the ebdb-vm part is
>> quick&dirty, leaving a lot of warnings when VM is not installed, some
>> of them may be real bugs).
> I thought about extracting those two into separate packages, and
> probably should have done that.

That's one way to solve the problem, but it's not necessary.

> Actually, I do know: vm and mu4e aren't installable via the package
> manager.  If I make separate packages, and put a package-requires header
> in them for vm and mu4e, will package.el be satisfied if a user has
> installed them via other means? Or will it bark?

It will bark :-(

> Another option would be a boatload of (autoload 'function "ext:vm")
> statements.

For ebdb-mu4e, I think the patch I send leads to correct results, so
I think it's an acceptable solution.

For VM, I'm not sure if the result is correct.  It basically depends on
whether part of the VM code are needed during compilation (most common
case is if your code uses VM macros).

Fixing the warnings is easy enough (rather than autoloads, you can use
`declare-function`).


        Stefan

Re: [ELPA] Package proposal: EBDB

[Eric Abrahamsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Huh, interesting.  Is that function completely deprecated, or still
>> usable for class-allocated slots?
>
> It's fine for class-allocated slots.
>
>>> - ebdb-vm and ebdb-mu4e will break the compilation of the package if the
>>> user doesn't have VM and mu4e installed.
>>> The appended patch tries to fix those two, but please take a look at it
>>> to make sure it still works correctly (especially the ebdb-vm part is
>>> quick&dirty, leaving a lot of warnings when VM is not installed, some
>>> of them may be real bugs).
>> I thought about extracting those two into separate packages, and
>> probably should have done that.
>
> That's one way to solve the problem, but it's not necessary.
>
>> Actually, I do know: vm and mu4e aren't installable via the package
>> manager.  If I make separate packages, and put a package-requires header
>> in them for vm and mu4e, will package.el be satisfied if a user has
>> installed them via other means? Or will it bark?
>
> It will bark :-(
>
>> Another option would be a boatload of (autoload 'function "ext:vm")
>> statements.
>
> For ebdb-mu4e, I think the patch I send leads to correct results, so
> I think it's an acceptable solution.
>
> For VM, I'm not sure if the result is correct.  It basically depends on
> whether part of the VM code are needed during compilation (most common
> case is if your code uses VM macros).
>
> Fixing the warnings is easy enough (rather than autoloads, you can use
> `declare-function`).

Okay, I'll apply your solution to ebdb-mu4e, then take a closer look at
vm.

Thanks,
Eric

Re: [ELPA] Package proposal: EBDB

[Eric Abrahamsen]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>

[...]

>> For VM, I'm not sure if the result is correct.  It basically depends on
>> whether part of the VM code are needed during compilation (most common
>> case is if your code uses VM macros).
>>
>> Fixing the warnings is easy enough (rather than autoloads, you can use
>> `declare-function`).
>
> Okay, I'll apply your solution to ebdb-mu4e, then take a closer look at
> vm.

Turns out it's a moot point, as VM only supports Emacs up to 23, two
major modes less than what EBDB requires. Before I found that out I did
get the compiler to keep quiet, at the cost of I think just one defsubst
that the compiler would never inline.

Oh well,
Eric

Re: [ELPA] Package proposal: EBDB

[Stefan Monnier]

> Turns out it's a moot point, as VM only supports Emacs up to 23, two
> major modes less than what EBDB requires.

It's probably easy to make it work with Emacs≥24, tho.

> Before I found that out I did get the compiler to keep quiet, at the
> cost of I think just one defsubst that the compiler would
> never inline.

Good, thanks,


        Stefan

Re: [ELPA] Package proposal: EBDB

[Eric Abrahamsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Turns out it's a moot point, as VM only supports Emacs up to 23, two
>> major modes less than what EBDB requires.

Major *version numbers*.

> It's probably easy to make it work with Emacs≥24, tho.

Sorry, do you mean VM or EBDB? VM is out of my hands... I ran "make", it
bailed when it couldn't find Emacs 23, and I gave up there.

EBDB currently uses seq, which requires Emacs 25. I could remove that
dependency, but I sure like seq. Pcase is Emacs 24, and I don't think
I'm willing to give up pcase.

Eric

Re: [ELPA] Package proposal: EBDB

[Stefan Monnier]

>> It's probably easy to make it work with Emacs≥24, tho.
> Sorry, do you mean VM or EBDB?

I mean VM.

> VM is out of my hands...

I know.  I just mean that that the work you did on ebdb-vm is not
necessarily wasted, because it'll probably not take much time from
someone motivated to make VM work on Emacs-25, so it'll likely happen at
some point.

> EBDB currently uses seq, which requires Emacs 25. I could remove that
> dependency, but I sure like seq. Pcase is Emacs 24, and I don't think
> I'm willing to give up pcase.

I think it'll be easier (and preferable) to move VM up to Emacs-25 ;-)
So we can just wait,


        Stefan

Re: [ELPA] Package proposal: EBDB

[Eric Abrahamsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> It's probably easy to make it work with Emacs≥24, tho.
>> Sorry, do you mean VM or EBDB?
>
> I mean VM.
>
>> VM is out of my hands...
>
> I know.  I just mean that that the work you did on ebdb-vm is not
> necessarily wasted, because it'll probably not take much time from
> someone motivated to make VM work on Emacs-25, so it'll likely happen at
> some point.

Gotcha. They have a fairly active ML, I'll poke a little bit.