Package Requiring a Commit?

Package Requiring a Commit?

[Jai Flack]

Greetings Emacs Developers,

Is there a preferred way for a package to Package-Requires on an Emacs
version more recent than the latest release? The context for this my
package isearch-olc [1] which I would like to finish testing and submit
for inclusion in GNU ELPA soon, however it requires
lazy-count-update-hook which was only introduced in a recent-ish commit.

Is the preferred solution to check for special-variable-p and error
(possibly message on load and error on mode enable) if it hasn't been
defined yet?

[1] https://git.disroot.org/jflack/isearch-olc

-- 
Thanks,
Jai

Re: Package Requiring a Commit?

[Filipp Gunbin]

On 04/05/2022 11:44 +0000, Jai Flack wrote:

> Greetings Emacs Developers,
>
> Is there a preferred way for a package to Package-Requires on an Emacs
> version more recent than the latest release? The context for this my
> package isearch-olc [1] which I would like to finish testing and submit
> for inclusion in GNU ELPA soon, however it requires
> lazy-count-update-hook which was only introduced in a recent-ish commit.
>
> Is the preferred solution to check for special-variable-p and error
> (possibly message on load and error on mode enable) if it hasn't been
> defined yet?

This should work, just use next version:

;; Package-Requires: ((emacs "29"))

Then people running Emacs which was built recently from master will be
able to install your package, because they're "already on 29".

Filipp

Re: Package Requiring a Commit?

[Jai Flack]

Filipp Gunbin <fgunbin@fastmail.fm> writes:

> On 04/05/2022 11:44 +0000, Jai Flack wrote:
>
>> Greetings Emacs Developers,
>>
>> Is there a preferred way for a package to Package-Requires on an Emacs
>> version more recent than the latest release? The context for this my
>> package isearch-olc [1] which I would like to finish testing and submit
>> for inclusion in GNU ELPA soon, however it requires
>> lazy-count-update-hook which was only introduced in a recent-ish commit.
>>
>> Is the preferred solution to check for special-variable-p and error
>> (possibly message on load and error on mode enable) if it hasn't been
>> defined yet?
>
> This should work, just use next version:
>
> ;; Package-Requires: ((emacs "29"))
>
> Then people running Emacs which was built recently from master will be
> able to install your package, because they're "already on 29".
>
> Filipp

Thanks that solves one of the issues. Is there no good solution to the
other? I can imagine some users building from master for a specific
feature (say, PGTK) and then not updating.

-- 
Thanks,
Jai

Re: Package Requiring a Commit?

[Tassilo Horn]

Jai Flack <jflack@posteo.net> writes:

>> This should work, just use next version:
>>
>> ;; Package-Requires: ((emacs "29"))
>>
>> Then people running Emacs which was built recently from master will be
>> able to install your package, because they're "already on 29".
>
> Thanks that solves one of the issues. Is there no good solution to the
> other? I can imagine some users building from master for a specific
> feature (say, PGTK) and then not updating.

For something like "at least as new as commit XXX" Emacs would need to
carry its complete commit graph with it in order to check that
requirement.

So it's best to just require emacs 29.  I personally have no big empathy
for people running outdated development snapshots [1] but if you do, it
shouldn't be too hard to fail gracefully by testing for
functions/variables you need using (f)boundp.

Bye,
Tassilo

[1] Simply because during development it may happen that new things are
    tweaked/renamed many times until finished.

Re: Package Requiring a Commit?

[Filipp Gunbin]

On 05/05/2022 07:46 +0000, Jai Flack wrote:

> Filipp Gunbin <fgunbin@fastmail.fm> writes:
>
>> On 04/05/2022 11:44 +0000, Jai Flack wrote:
>>
>>> Greetings Emacs Developers,
>>>
>>> Is there a preferred way for a package to Package-Requires on an Emacs
>>> version more recent than the latest release? The context for this my
>>> package isearch-olc [1] which I would like to finish testing and submit
>>> for inclusion in GNU ELPA soon, however it requires
>>> lazy-count-update-hook which was only introduced in a recent-ish commit.
>>>
>>> Is the preferred solution to check for special-variable-p and error
>>> (possibly message on load and error on mode enable) if it hasn't been
>>> defined yet?
>>
>> This should work, just use next version:
>>
>> ;; Package-Requires: ((emacs "29"))
>>
>> Then people running Emacs which was built recently from master will be
>> able to install your package, because they're "already on 29".
>>
>> Filipp
>
> Thanks that solves one of the issues. Is there no good solution to the
> other? I can imagine some users building from master for a specific
> feature (say, PGTK) and then not updating.

Sorry, I thought you were describing the _single_ problem.  I see
Tassilo replied to you, but if you still have questions - please tell
what they are.

Filipp

Re: Package Requiring a Commit?

[Jai Flack]

Tassilo Horn <tsdh@gnu.org> writes:

> Jai Flack <jflack@posteo.net> writes:
>
>>> This should work, just use next version:
>>>
>>> ;; Package-Requires: ((emacs "29"))
>>>
>>> Then people running Emacs which was built recently from master will be
>>> able to install your package, because they're "already on 29".
>>
>> Thanks that solves one of the issues. Is there no good solution to the
>> other? I can imagine some users building from master for a specific
>> feature (say, PGTK) and then not updating.
>
> For something like "at least as new as commit XXX" Emacs would need to
> carry its complete commit graph with it in order to check that
> requirement.
>
> So it's best to just require emacs 29.  I personally have no big empathy
> for people running outdated development snapshots [1] but if you do, it
> shouldn't be too hard to fail gracefully by testing for
> functions/variables you need using (f)boundp.
>
> Bye,
> Tassilo
>
> [1] Simply because during development it may happen that new things are
>     tweaked/renamed many times until finished.

I'm not necessarily after requiring specific commits but yes I suppose
something like that isn't a reasonable expectation.

-- 
Thanks,
Jai