Re: Adding the `prescient` packages to NonGNU ELPA?

[Philip Kaludercic]

Okamsn <okamsn@protonmail.com> writes:

> On 2022-11-20 17:42 UTC, Okamsn wrote:
>>>
>>>> All of these packages live in the same repository in the link below.
>>>
>>> Would it be possible to change this?  E.g. by making each project live
>>> on it's own branch.  That would make the :ignored-files rules below a
>>> lot simpler.
>>
>> I wouldn't mind making new branches that hold the stable versions. Are
>> you OK with the README and CHANGELOG still being duplicated in that case?
>>
>> ...
>
> After communicating with the other maintainers, they are requesting that
> I do not make this change (discussion here:
> https://github.com/radian-software/prescient.el/issues/138).

To clarify a point from this discussion, it is certainly possible to
arrange separate packages by excluding the other files, but it is a hack
that would be nice to avoid.  There are already a few packages (such as
Magit) that do something like this, but in general this kind of
packaging is a MELPA-ism.

> You mentioned that there are caveats for package-vc. If a user wanted to
> install a package using that feature (which I look forward to trying),
> is it possible to tell it the files that should be added (or not be
> added) to the load path?

Package-vc uses the ELPA model, and all it does is clone a repository
into your ~/.emacs.d/elpa directory and prepare it for activation
(byte-compiling, generating autoloads, etc.).  The rest is regular
package.el, so all the files in the respective directories are
accessible using `load'/`require'.

>>>> When I tried testing the installation of `prescient`, it installed
>>>> an older version of the file `prescient.el` than what is current in the
>>>> repository. This was the version that received an update to the version
>>>> number, but how does the system decide which is the most recent stable
>>>> version of a file? I might need to increase the number to make it
>>>> install a newer version.
>>>
>>> Yes, ELPA finds the last commit that changed the version header and uses
>>> that to prepare a release.
>>
>> OK. I will try updating the version number to make sure that was the
>> problem.
>>
>
> This was the problem.  The installation works after changing the version
> number. I have asked about the author's process for releasing a new
> minor version.

1+