Re: [elpa] scratch/email-revision-details

[Stefan Monnier]

Phil Sainty [2021-08-08 01:45:20] wrote:
> On 2021-08-07 03:30, Stefan Monnier wrote:
>> Feel free to push this to `master`, it looks good to me.
> Done.

Thanks.

> (Well, pushed to elpa-admin.)

Oops, indeed.

> For the other commit (just re-pushed to my scratch branch, but
> the code is unchanged), I'm not sure how to test it, aside from
> testing in isolation the part which actually gets the revision
> details from git for a given `release-rev' value (which I've
> tested against so-long.el).

I think you can test it as follows:

- Add to `elpa-config` the following elements:

      (email-to              "Phil Sainty <psainty@orcon.net.nz>")
      (email-from            "Phil Sainty <psainty@orcon.net.nz>")
      (email-reply-to        "Phil Sainty <psainty@orcon.net.nz>")

  [ Or use some other email address, of course.  ]

- `rm archive/*`
- `make build/so-long`

This should presumably build a "new" release tarball and send an email
to the `email-to` address (with Cc to the package's maintainer).

The email is sent by Emacs, so the actual sending may fail depending on
how your Emacs config is setup.

> I've gone with the full compliment of author+commit timestamps
> in both relative and absolute formats, which looks like this:
>
> ; * lisp/so-long.el: Bump version for the GNU ELPA build
> Authored 3 days ago on Wed, 4 Aug 2021 17:17:23 +1200
> Committed 3 days ago on Wed, 4 Aug 2021 17:17:23 +1200
> Revision b84986af52d4e9debace2850a5ec106f51e38e61

That looks great (I like those times).
I'd just add a short line before that explaining what those lines
represent (for the non-expert user who's not familiar with VCS), and
add some indentation to clarify that the lines belong together.
Maybe something like:

    Built from revision <COMMITID>:
      ; * lisp/so-long.el: Bump version for the GNU ELPA build
      Authored 3 days ago on Wed, 4 Aug 2021 17:17:23 +1200
      Committed 3 days ago on Wed, 4 Aug 2021 17:17:23 +1200

If we wanted to get fancy we could remove one of the two last lines in
case (like here) the times are equal (since that should be a fairly
common case).

> If the code looks sane to you, are you able to test it, or
> let me know how to safely do that?  I see the commented debug
> line ahead of the (message-send) call, but I don't know whether
> that's the only code that I'd need to be concerned about.

You could uncomment that line and then instead of `make build/so-long`
I think you can use

    emacs -l $(pwd)/admin/elpa-admin.el \
          -f elpaa-batch-make-one-package so-long

But I'm not completely sure: when I used that debug line, I think
I called internal functions more directly from an interactive
Emacs session (I had those things still fairly fresh in my mind).

Looking at my question/suggestion not to use a global var and to fetch
the commit's info only when we actually send the message, I see that
`elpaa--release-email` can't easily do that right now because it doesn't
know the commitid.

I think the best way to do that is:

- Make it so `elpaa--release-email` is called directly from
  `elpaa--make-one-tarball` when `revision-function` is non-nil.
  [ AFAICT `elpaa--release-email` is called if-and-only-if
    `revision-function` is non-nil and always in the same way, so this
    would improve/simplify the code.  ]
- Change `elpaa--make-one-tarball` to remember the commit id returned by
  `revision-function`, so we can pass it to `elpaa--release-email`.
- Then we can write a new function to get the commitid's data using the
  same

      (let* ((mainfile (file-truename
                        (expand-file-name (elpaa--main-file pkg-spec)
                                          (elpaa--dirname dir))))
             (default-directory (file-name-directory mainfile))

  as in `elpaa--get-release-revision`.
- use that function from `elpaa--release-email`.


        Stefan