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

[Stefan Monnier]

Sean Whitton [2022-12-18 16:36:56] wrote:
>     * elpa-packages (notmuch): New package.

FWIW, I think this is a mistake  because:

> + (notmuch               :url "https://git.notmuchmail.org/git/notmuch";

This is not a repository containing the Emacs Notmuch package but
a repository containing the Notmuch command line MUA tools, and within
which they decided to also keep their Emacs front end.
[ The ELisp code is about 7% of the total in there :-(  ]

The (Non)GNU ELPA infrastructure is ill-equipped to handle such setups
(for that reason we don't have an `erlang-mode` package).

> +  :ignored-files
> +  ("emacs/make-deps.el" "emacs/Makefile*" "emacs/*.tmpl" "emacs/rstdoc.*"
> +   "emacs/notmuch-emacs-mua*" "bindings" "compat" "completion" "contrib"
> +   "debian" "devel" "doc" "lib" "packaging" "parse-time-string" "COPYING"
> +   "performance-test" "test" "util" "vim" "*.c" "*.h" "configure"
> +   "INSTALL" "Makefile*" "README.rst" "notmuch-git.py" "version.txt"
> +   ".travis.yml" "sh.config" "sphinx.config" ".mailmap" "COPYING-GPL-3")

Reads hellish to me.  This is crap *we* have to maintain in response to
whatever happens upstream.

> +  :make ("emacs/notmuch-pkg.el" "emacs/notmuch-version.el")

(Non)GNU ELPA really wants to create the <foo>-pkg.el from the headers
in the <foo>.el main file.  The above may sometimes work but will bite
us sooner or later.

> +  ;; FIXME: notmuch-pkg.el is not committed to Git.

Please don't fix this.  If it's in the Git it gets worse (tends to
create spurious conflicts while building the package.  Our scripts
*should* be resilient to such problems, but based on past experience,
I doubt they are yet in all cases).

> +  ;; Upstream are amenable to making changes in this area, but they have a
> +  ;; number of build targets that involve generated snapshot version numbers,
> +  ;; and we would need to confirm that committing notmuch-pkg.el doesn't
> +  ;; interfere too much with any of those.

That's in large part due to the repository not being for Emacs's package
for something else (related, admittedly, yet different and hence faced
with lots of other constraints).

The fix should start by adding a `Version:` to the `notmuch.el` file.
There's no deep reason why the Emacs UI's version should evolve in
lockstep with the Notmuch MUA itself.

But in any case, a `grep 0.37` in the repository shows that they already
have two copies of the version number (one in `version.txt` and one in
`bindings/python/notmuch/version.py`), so adding a third shouldn't
be a big deal.

> +  ;; 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).

BTW, the build of the tarball currently fails in the `:make` command
because it looks for Git info that's not available in the sandbox
(probably to build a "short Git revision name" but since we don't have
the tags of notmuch.git, that won't do what's expected even if we fix
make the sandbox more lax) and also because it tries to compile a C file
(probably to extract some info from something like `notmuch.h`) but
`elpa.gnu.org` doesn't have a C compiler.  There might be further
problems along the way.


        Stefan