Re: [nongnu] main 385623dca6 2/2: * elpa-packages (notmuch): New package.

[Stefan Monnier]

>> Reads hellish to me.  This is crap *we* have to maintain in response to
>> whatever happens upstream.
>
> I think that maintaining notmuch.el inside the rest of notmuch.git is a
> reasonable choice by notmuch upstream; I do the same in two of my
> projects where the non-Elisp heavily outweighs the Elisp.

I'm not blaming them.  I do think nowadays their users would be better
served by decoupling the two, tho.  And indeed, the Debian package
`elpa-notmuch` does not depend on a specific version of the `notmuch`
tools, so in practice the two seem to be sufficiently decoupled that
they can evolve separately.

> Perhaps we could overcome this particular limitation in the scripts.
> How about adding :files or :include, or similar, where if that's
> present, then only files matching the globs listed are taken up, and
> everything else is ignored?

The problem is not with the tarball, but with the Git side.  (Non)GNU
ELPA is not just an archive of tarballs, but it's built around Git
repositories hosting the relevant code and its full history.

While I hope Git grows support for "partial clones" (or more likely is
superseded by something else which does support such things), the
current situation is that you just can't do that.  Which means
`elpa-diffs` will be spammed with irrelevant commit to the non-Emacs
part of Notmuch, for example, and `package-vc` will still have to
download the 10MB of Notmuch's repository just to get at the relevant
0.5MB.

The closest we can get, AFAIK, is to run an interposer repository which
fetches from https://git.notmuchmail.org/git/notmuch and filters the
`emacs` subtree into a new branch, and then add *that* branch to
`elpa-packages`.  Of course, that creates a whole parallel history, so
it may end up biting us down the line, but I think given the current
situation it'd the "least wrong" way to do it (The Right Way being if
they do that split upstream and then use the new branch as the official
upstream).

> (Additionally and less importantly, I would like to add mailscripts.el
> to NonGNU ELPA, as you know, and mailscripts.el depends on notmuch.el.)

I understand the desire to add Notmuch, yes.
I'd be happy to see it in (Non)GNU ELPA as well.

>>> +  ;; Alternatively, could we have elpa-admin run 'make 
>>> emacs/notmuch-pkg.el'
>>> +  ;; before looking for a version?
>>> +  :version-map ((nil "0.37" "0.37")))
>> This 3rd element should be a Git revision (IOW a commit id).
> 0.37 is a committish,[1] if not a commit;

"0.37" of what?  Remember we're talking about `nongnu.git` which contains
*all* the NonGNU ELPA packages.  So, upstream tags don't make much sense
there (and for that reason also they're not pulled from upstream).

> isn't that okay?

[ And hence: no, it's not okay, I'm afraid.  ]

It would be good to add optional support for using Git tags to label
versions (probably via renaming the tags from `<foo>` to
`upstream/<pkg>/<foo>` or something like that), but I'm still waiting for
Someone™ to write that code.


        Stefan