Adding the `prescient` packages to NonGNU ELPA?

Adding the `prescient` packages to NonGNU ELPA?

[Okamsn]

[-- Attachment #1: Type: text/plain, Size: 1421 bytes --]

Hello,

Would you be willing to add Prescient[1] and some of its related
packages to NonGNU ELPA, as in the attached file? I am one of the
maintainers of this package. The author of the package does not wish to
assign copyright or require others to do so, so it cannot be added to
GNU ELPA.

Prescient is for sorting and filtering completion candidates. Its
filtering is similar to the package Orderless and it sorts by a
combination of the frequency and the recency of the candidates.

These are the packages I am wondering if you would be willing to add:

- `prescient`: The base package, which provides the sorting and
    filtering functions and a completion style

- `company-prescient`: Use `prescient` sorting with Company

- `corfu-prescient`: Use `prescient` sorting and filtering with Corfu

- `vertico-prescient`: Use `prescient` sorting and filtering with Vertico

All of these packages live in the same repository in the link below.

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.

Thank you.


[1]: https://github.com/radian-software/prescient.el

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-First-attempt-at-adding-packages.patch --]
[-- Type: text/x-patch; name=0001-First-attempt-at-adding-packages.patch, Size: 2507 bytes --]

From f2d4107036e5be8b97de83663e47aeb5a670a301 Mon Sep 17 00:00:00 2001
From: okamsn <okamsn@protonmail.com>
Date: Sat, 19 Nov 2022 21:13:05 -0500
Subject: [PATCH] First attempt at adding packages.

---
 elpa-packages | 40 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 40 insertions(+)

diff --git a/elpa-packages b/elpa-packages
index eb69320ee2..a15d60370b 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -484,6 +484,46 @@
  ("popup"		:url "https://github.com/auto-complete/popup-el"
   :ignored-files ("LICENSE"))
 
+ ("prescient"           :url "https://github.com/radian-software/prescient.el"
+  :branch "main"
+  :news "CHANGELOG.md"
+  :mainfile "prescient.el"
+  :readme "README.md"
+  :ignored-files ("Dockerfile" "LICENSE.md" "Makefile" "company-prescient.el"
+                  "corfu-prescient.el" "ivy-prescient.el" "scripts"
+                  "selectrum-prescient.el" "stub" "vertico-prescient.el"
+                  ".dir-locals.el" ".github" ".gitignore"))
+
+ ("vertico-prescient"   :url "https://github.com/radian-software/prescient.el"
+  :branch "main"
+  :news "CHANGELOG.md"
+  :mainfile "vertico-prescient.el"
+  :readme "README.md"
+  :ignored-files ("Dockerfile" "LICENSE.md" "Makefile" "company-prescient.el"
+                  "corfu-prescient.el" "ivy-prescient.el" "prescient.el"
+                  "scripts" "selectrum-prescient.el" "stub" ".dir-locals.el"
+                  ".github" ".gitignore"))
+
+ ("corfu-prescient"     :url "https://github.com/radian-software/prescient.el"
+  :branch "main"
+  :news "CHANGELOG.md"
+  :mainfile "corfu-prescient.el"
+  :readme "README.md"
+  :ignored-files ("Dockerfile" "LICENSE.md" "Makefile" "company-prescient.el"
+                  "ivy-prescient.el" "prescient.el" "scripts"
+                  "selectrum-prescient.el" "stub" "vertico-prescient.el"
+                  ".dir-locals.el" ".github" ".gitignore"))
+
+ ("company-prescient"   :url "https://github.com/radian-software/prescient.el"
+  :branch "main"
+  :news "CHANGELOG.md"
+  :mainfile "company-prescient.el"
+  :readme "README.md"
+  :ignored-files ("Dockerfile" "LICENSE.md" "Makefile" "corfu-prescient.el"
+                  "ivy-prescient.el" "prescient.el" "scripts"
+                  "selectrum-prescient.el" "stub" "vertico-prescient.el"
+                  ".dir-locals.el" ".github" ".gitignore"))
+
  ("projectile"  	:url "https://github.com/bbatsov/projectile"
   :ignored-files ("LICENSE" "doc" "test")
   :news "CHANGELOG.md")
-- 
2.34.1

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

[Philip Kaludercic]

Okamsn <okamsn@protonmail.com> writes:

> Hello,

Hi,

> Would you be willing to add Prescient[1] and some of its related
> packages to NonGNU ELPA, as in the attached file? I am one of the
> maintainers of this package. The author of the package does not wish to
> assign copyright or require others to do so, so it cannot be added to
> GNU ELPA.
>
> Prescient is for sorting and filtering completion candidates. Its
> filtering is similar to the package Orderless and it sorts by a
> combination of the frequency and the recency of the candidates.

From what I recall, Vertico does that too, but Vertico is a completion
front-end?  Intuitively I would have also guessed that the front-end is
the right place to solve this problem.

Or maybe to rephrase the question, what does this package provide over
vertico + orderless?

> These are the packages I am wondering if you would be willing to add:
>
> - `prescient`: The base package, which provides the sorting and
>     filtering functions and a completion style
>
> - `company-prescient`: Use `prescient` sorting with Company
>
> - `corfu-prescient`: Use `prescient` sorting and filtering with Corfu
>
> - `vertico-prescient`: Use `prescient` sorting and filtering with Vertico

Could you explain the need for these other packages?  If we are talking
about a completion style, why do other packages require their own
support?

> 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.

> 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.

> Thank you.
>
>
> [1]: https://github.com/radian-software/prescient.el
>
> From f2d4107036e5be8b97de83663e47aeb5a670a301 Mon Sep 17 00:00:00 2001
> From: okamsn <okamsn@protonmail.com>
> Date: Sat, 19 Nov 2022 21:13:05 -0500
> Subject: [PATCH] First attempt at adding packages.
>
> ---
>  elpa-packages | 40 ++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 40 insertions(+)
>
> diff --git a/elpa-packages b/elpa-packages
> index eb69320ee2..a15d60370b 100644
> --- a/elpa-packages
> +++ b/elpa-packages
> @@ -484,6 +484,46 @@
>   ("popup"		:url "https://github.com/auto-complete/popup-el"
>    :ignored-files ("LICENSE"))
>  
> + ("prescient"           :url "https://github.com/radian-software/prescient.el"
> +  :branch "main"
> +  :news "CHANGELOG.md"
> +  :mainfile "prescient.el"
> +  :readme "README.md"
> +  :ignored-files ("Dockerfile" "LICENSE.md" "Makefile" "company-prescient.el"
> +                  "corfu-prescient.el" "ivy-prescient.el" "scripts"
> +                  "selectrum-prescient.el" "stub" "vertico-prescient.el"
> +                  ".dir-locals.el" ".github" ".gitignore"))
> +
> + ("vertico-prescient"   :url "https://github.com/radian-software/prescient.el"
> +  :branch "main"
> +  :news "CHANGELOG.md"
> +  :mainfile "vertico-prescient.el"
> +  :readme "README.md"
> +  :ignored-files ("Dockerfile" "LICENSE.md" "Makefile" "company-prescient.el"
> +                  "corfu-prescient.el" "ivy-prescient.el" "prescient.el"
> +                  "scripts" "selectrum-prescient.el" "stub" ".dir-locals.el"
> +                  ".github" ".gitignore"))
> +
> + ("corfu-prescient"     :url "https://github.com/radian-software/prescient.el"
> +  :branch "main"
> +  :news "CHANGELOG.md"
> +  :mainfile "corfu-prescient.el"
> +  :readme "README.md"
> +  :ignored-files ("Dockerfile" "LICENSE.md" "Makefile" "company-prescient.el"
> +                  "ivy-prescient.el" "prescient.el" "scripts"
> +                  "selectrum-prescient.el" "stub" "vertico-prescient.el"
> +                  ".dir-locals.el" ".github" ".gitignore"))
> +
> + ("company-prescient"   :url "https://github.com/radian-software/prescient.el"
> +  :branch "main"
> +  :news "CHANGELOG.md"
> +  :mainfile "company-prescient.el"
> +  :readme "README.md"
> +  :ignored-files ("Dockerfile" "LICENSE.md" "Makefile" "corfu-prescient.el"
> +                  "ivy-prescient.el" "prescient.el" "scripts"
> +                  "selectrum-prescient.el" "stub" "vertico-prescient.el"
> +                  ".dir-locals.el" ".github" ".gitignore"))
> +
>   ("projectile"  	:url "https://github.com/bbatsov/projectile"
>    :ignored-files ("LICENSE" "doc" "test")
>    :news "CHANGELOG.md")

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

[Stefan Kangas]

Philip Kaludercic <philipk@posteo.net> writes:

>> 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.

We could also make the rules simpler by adding support for the inverse
of :ignored-packages.

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

[Stefan Monnier]

Stefan Kangas [2022-11-20 03:23:09] wrote:
> Philip Kaludercic <philipk@posteo.net> writes:
>>> 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.
>
> We could also make the rules simpler by adding support for the inverse
> of :ignored-packages.

Multi-package repositories are fundamentally incompatible with
`package-vc` (they kind of work, but with various caveats).
So I think we definitely don't want to support them better, but instead
we should discourage them.  If we want to invest efforts in that
direction it should be efforts to make it easier to "re-merge" packages
so as to move away from the problem.


        Stefan

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

[Philip Kaludercic]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Stefan Kangas [2022-11-20 03:23:09] wrote:
>> Philip Kaludercic <philipk@posteo.net> writes:
>>>> 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.
>>
>> We could also make the rules simpler by adding support for the inverse
>> of :ignored-packages.
>
> Multi-package repositories are fundamentally incompatible with
> `package-vc` (they kind of work, but with various caveats).

They will have the same issues as elpa-admin has, right?  In that case,
the issue will be if someone just wants to install prescient, they will
have all the other dependencies unconditionally "installed" along with
the rest.  At the same time, if someone installs one of the more
specialised packages, which adds the same repository as a dependency,
you'll have the same package checked out twice, and I would have to
guess which takes priority in `load-path'...

> So I think we definitely don't want to support them better, but instead
> we should discourage them.  If we want to invest efforts in that
> direction it should be efforts to make it easier to "re-merge" packages
> so as to move away from the problem.

Agreed.

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

People are talking about something called "prescient".  What is it?
What jobs does it do?  Is there a drawback in these jobs?  If those
topics were discussed, I did not see it.  But they are the most important
questions about that something,

The discussion is focusing on practical issues of merging them, but we
should also think about whether the presence of this facility has any
drawbacks.

Perhaps "prescient" is just "more of the same," convenient features
with no deep implications.  Let's have a discussion of what it does,
so we can see whether that is true or not.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

[Akib Azmain Turja]

[-- Attachment #1: Type: text/plain, Size: 1681 bytes --]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> People are talking about something called "prescient".  What is it?
> What jobs does it do?  Is there a drawback in these jobs?  If those
> topics were discussed, I did not see it.  But they are the most important
> questions about that something,
>
> The discussion is focusing on practical issues of merging them, but we
> should also think about whether the presence of this facility has any
> drawbacks.
>
> Perhaps "prescient" is just "more of the same," convenient features
> with no deep implications.  Let's have a discussion of what it does,
> so we can see whether that is true or not.

Prescient is sorting and filter packages for completion UIs.  It sorts
candidates using frecency (frequency and recency).  For example, if you
select 'grep' in your M-x prompt using one of the supported UIs, 'grep'
will be placed earlier among the candidates next time.  If you use
another supported auto-completion UI like Company or Corfu, Prescient
will use the data it gathered from other UIs to sort the candidates.

It does the sorting and filtering with some simple algorithms, so I
don't think it has any implications.

[ Disclaimer: I longer use Prescient, so this might be outdated. ]

-- 
Akib Azmain Turja, GPG key: 70018CE5819F17A3BBA666AFE74F0EFA922AE7F5
Fediverse: akib@hostux.social
Codeberg: akib
emailselfdefense.fsf.org | "Nothing can be secure without encryption."

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

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

[okamsn]

On 2022-11-22 13:53 UTC, Akib Azmain Turja wrote:
> Richard Stallman <rms@gnu.org> writes:
>
>> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
>> [[[ whether defending the US Constitution against all enemies,     ]]]
>> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>>
>> People are talking about something called "prescient".  What is it?
>> What jobs does it do?  Is there a drawback in these jobs?  If those
>> topics were discussed, I did not see it.  But they are the most important
>> questions about that something,
>>
>> The discussion is focusing on practical issues of merging them, but we
>> should also think about whether the presence of this facility has any
>> drawbacks.
>>
>> Perhaps "prescient" is just "more of the same," convenient features
>> with no deep implications.  Let's have a discussion of what it does,
>> so we can see whether that is true or not.
>
> Prescient is sorting and filter packages for completion UIs.  It sorts
> candidates using frecency (frequency and recency).  For example, if you
> select 'grep' in your M-x prompt using one of the supported UIs, 'grep'
> will be placed earlier among the candidates next time.  If you use
> another supported auto-completion UI like Company or Corfu, Prescient
> will use the data it gathered from other UIs to sort the candidates.
>
> It does the sorting and filtering with some simple algorithms, so I
> don't think it has any implications.
>
> [ Disclaimer: I longer use Prescient, so this might be outdated. ]
>

This description is accurate.

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > Prescient is sorting and filter packages for completion UIs.  It sorts
  > > candidates using frecency (frequency and recency).  For example, if you
  > > select 'grep' in your M-x prompt using one of the supported UIs, 'grep'
  > > will be placed earlier among the candidates next time.  If you use
  > > another supported auto-completion UI like Company or Corfu, Prescient
  > > will use the data it gathered from other UIs to sort the candidates.
  > >
  > > It does the sorting and filtering with some simple algorithms, so I
  > > don't think it has any implications.

Thanks.  Now everyone reading the list can see what features you're
proposing to add.

I don't have any opinions about them myself.


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

[Visuwesh]

[ஞாயிறு நவம்பர் 20, 2022] Philip Kaludercic wrote:

>> [...]
>> These are the packages I am wondering if you would be willing to add:
>>
>> - `prescient`: The base package, which provides the sorting and
>>     filtering functions and a completion style
>>
>> - `company-prescient`: Use `prescient` sorting with Company
>>
>> - `corfu-prescient`: Use `prescient` sorting and filtering with Corfu
>>
>> - `vertico-prescient`: Use `prescient` sorting and filtering with Vertico
>
> Could you explain the need for these other packages?  If we are talking
> about a completion style, why do other packages require their own
> support?

AFAIU, it is because there is no common way to call a function after
ending a completing-read and/or completion-in-region call so we end up
needing a UI specific way to do so.  The function records the selected
candidate, necessary for fuzzy(?) matching based on frequency and
recency ("frecency").
The README does a better job at explaining this than I do here (which is
based on understanding on how the package worked before it underwent
extensive rewrite).

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

[Stefan Monnier]

> AFAIU, it is because there is no common way to call a function after
> ending a completing-read and/or completion-in-region call so we end up
> needing a UI specific way to do so.  The function records the selected
> candidate, necessary for fuzzy(?) matching based on frequency and
> recency ("frecency").

Hmm.. indeed we have no way in the framework to let the UI tell the
completion-table or the completion-style which candidate was chosen in
the end.  The closest we have is the history variables (and that's only
available for minibuffer completions).
:-(


        Stefan

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

[North Year]

On 11/20/22 22:40, Visuwesh wrote:
>>>
>>> - `company-prescient`: Use `prescient` sorting with Company
>>>
>>> - `corfu-prescient`: Use `prescient` sorting and filtering with Corfu
>>>
>>> - `vertico-prescient`: Use `prescient` sorting and filtering with Vertico
>>
>> Could you explain the need for these other packages?  If we are talking
>> about a completion style, why do other packages require their own
>> support?
>
>AFAIU, it is because there is no common way to call a function after
>ending a completing-read and/or completion-in-region call so we end up
>needing a UI specific way to do so.  The function records the selected
>candidate, necessary for fuzzy(?) matching based on frequency and
>recency ("frecency").
>The README does a better job at explaining this than I do here (which is
>based on understanding on how the package worked before it underwent
>extensive rewrite).

Why `prescient`, `company-prescient`, `corfu-prescient`,
`vertico-prescient` need to be separate packages? Can't they bundle
together as a single package? Eglot has additional support for company
despite that company isn't a builtin package yet, and eglot doesn't have
a `company-eglot` additional package.

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

[Philip Kaludercic]

North Year <ny-ml@outlook.com> writes:

> On 11/20/22 22:40, Visuwesh wrote:
>>>>
>>>> - `company-prescient`: Use `prescient` sorting with Company
>>>>
>>>> - `corfu-prescient`: Use `prescient` sorting and filtering with Corfu
>>>>
>>>> - `vertico-prescient`: Use `prescient` sorting and filtering with Vertico
>>>
>>> Could you explain the need for these other packages?  If we are talking
>>> about a completion style, why do other packages require their own
>>> support?
>>
>>AFAIU, it is because there is no common way to call a function after
>>ending a completing-read and/or completion-in-region call so we end up
>>needing a UI specific way to do so.  The function records the selected
>>candidate, necessary for fuzzy(?) matching based on frequency and
>>recency ("frecency").
>>The README does a better job at explaining this than I do here (which is
>>based on understanding on how the package worked before it underwent
>>extensive rewrite).
>
> Why `prescient`, `company-prescient`, `corfu-prescient`,
> `vertico-prescient` need to be separate packages? Can't they bundle
> together as a single package? Eglot has additional support for company
> despite that company isn't a builtin package yet, and eglot doesn't have
> a `company-eglot` additional package.

This has already been discussed in the thread, and it appears the head
maintainer is opposed to this approach.  I think it is a pity, as you
say it usually is not problem to add optional support for a package that
may or may not be installed (bbdb is another example that does this well).

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

[Stefan Monnier]

>> Why `prescient`, `company-prescient`, `corfu-prescient`,
>> `vertico-prescient` need to be separate packages? Can't they bundle
>> together as a single package? Eglot has additional support for company
>> despite that company isn't a builtin package yet, and eglot doesn't have
>> a `company-eglot` additional package.
>
> This has already been discussed in the thread, and it appears the head
> maintainer is opposed to this approach.  I think it is a pity, as you
> say it usually is not problem to add optional support for a package that
> may or may not be installed (bbdb is another example that does this well).

Is there anything that would prevent us from packaging all the files in
a single tarball?


        Stefan

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

[Philip Kaludercic]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> Why `prescient`, `company-prescient`, `corfu-prescient`,
>>> `vertico-prescient` need to be separate packages? Can't they bundle
>>> together as a single package? Eglot has additional support for
>>> company
>>> despite that company isn't a builtin package yet, and eglot doesn't
>>> have
>>> a `company-eglot` additional package.
>>
>> This has already been discussed in the thread, and it appears the head
>> maintainer is opposed to this approach.  I think it is a pity, as you
>> say it usually is not problem to add optional support for a package
>> that
>> may or may not be installed (bbdb is another example that does this
>> well).
>
> Is there anything that would prevent us from packaging all the files in
> a single tarball?

The only issue I can think about is if later on someone else wants to
add a package that depends on a specific "sub-package", and they find
themselves in a conflict specifying their dependency list, in case this
hypothetical package is to be distributed both via ELPA and MELPA.

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

[Stefan Monnier]

> The only issue I can think about is if later on someone else wants to
> add a package that depends on a specific "sub-package", and they find
> themselves in a conflict specifying their dependency list, in case this
> hypothetical package is to be distributed both via ELPA and MELPA.

Not our problem?


        Stefan

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

[Philip Kaludercic]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> The only issue I can think about is if later on someone else wants to
>> add a package that depends on a specific "sub-package", and they find
>> themselves in a conflict specifying their dependency list, in case this
>> hypothetical package is to be distributed both via ELPA and MELPA.
>
> Not our problem?

So let it be written, so let it be done.

I will prepare the package with everything bundled into a single
package, and see if that works out.

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

[Philip Kaludercic]

[-- Attachment #1: Type: text/plain, Size: 3075 bytes --]

Philip Kaludercic <philipk@posteo.net> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>> The only issue I can think about is if later on someone else wants to
>>> add a package that depends on a specific "sub-package", and they find
>>> themselves in a conflict specifying their dependency list, in case this
>>> hypothetical package is to be distributed both via ELPA and MELPA.
>>
>> Not our problem?
>
> So let it be written, so let it be done.
>
> I will prepare the package with everything bundled into a single
> package, and see if that works out.

As I had suspected, the main issue is that byte-compilation fails:

--8<---------------cut here---------------start------------->8---
make -k packages/prescient
Byte compiling packages/prescient/company-prescient.el
Error loading autoloads: (file-missing Cannot open load file No such file or directory /home/philip/Source/nongnu/packages/elfeed/elfeed-autoloads)

In toplevel form:
packages/prescient/company-prescient.el:29:2: Error: Cannot open load file: No such file or directory, company
make: *** [GNUmakefile:119: packages/prescient/company-prescient.elc] Error 1
Byte compiling packages/prescient/corfu-prescient.el
Error loading autoloads: (file-missing Cannot open load file No such file or directory /home/philip/Source/nongnu/packages/elfeed/elfeed-autoloads)

In toplevel form:
packages/prescient/corfu-prescient.el:27:2: Error: Cannot open load file: No such file or directory, corfu
make: *** [GNUmakefile:119: packages/prescient/corfu-prescient.elc] Error 1
Byte compiling packages/prescient/ivy-prescient.el
Error loading autoloads: (file-missing Cannot open load file No such file or directory /home/philip/Source/nongnu/packages/elfeed/elfeed-autoloads)

In toplevel form:
packages/prescient/ivy-prescient.el:32:2: Error: Cannot open load file: No such file or directory, ivy
make: *** [GNUmakefile:119: packages/prescient/ivy-prescient.elc] Error 1
Byte compiling packages/prescient/selectrum-prescient.el
Error loading autoloads: (file-missing Cannot open load file No such file or directory /home/philip/Source/nongnu/packages/elfeed/elfeed-autoloads)

In toplevel form:
packages/prescient/selectrum-prescient.el:27:2: Error: Cannot open load file: No such file or directory, selectrum
make: *** [GNUmakefile:119: packages/prescient/selectrum-prescient.elc] Error 1
Byte compiling packages/prescient/vertico-prescient.el
Error loading autoloads: (file-missing Cannot open load file No such file or directory /home/philip/Source/nongnu/packages/elfeed/elfeed-autoloads)

In toplevel form:
packages/prescient/vertico-prescient.el:29:2: Error: Cannot open load file: No such file or directory, vertico
make: *** [GNUmakefile:119: packages/prescient/vertico-prescient.elc] Error 1
make: Target 'packages/prescient' not remade because of errors.
--8<---------------cut here---------------end--------------->8---

But I guess this can be resolved upstream, if there is an interest.
Other than that, the tarball has a lot of administrative files.  I'd
recommend adding an .elpaignore:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-.elpaignore-Ignore-administrative-files.patch --]
[-- Type: text/x-diff, Size: 503 bytes --]

From 263d6101bb66216a62928cff5490ea05770b1397 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Sat, 17 Dec 2022 17:24:04 +0100
Subject: [PATCH] * .elpaignore: Ignore administrative files

---
 .elpaignore | 5 +++++
 1 file changed, 5 insertions(+)
 create mode 100644 .elpaignore

diff --git a/.elpaignore b/.elpaignore
new file mode 100644
index 0000000000..cf3e7575c2
--- /dev/null
+++ b/.elpaignore
@@ -0,0 +1,5 @@
+Dockerfile
+.github
+Makefile
+scripts
+stub
-- 
2.35.1

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

[Okamsn]

On 2022-12-17 16:24 UTC, Philip Kaludercic wrote:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>
>>>> The only issue I can think about is if later on someone else wants to
>>>> add a package that depends on a specific "sub-package", and they find
>>>> themselves in a conflict specifying their dependency list, in case this
>>>> hypothetical package is to be distributed both via ELPA and MELPA.
>>>
>>> Not our problem?
>>
>> So let it be written, so let it be done.
>>
>> I will prepare the package with everything bundled into a single
>> package, and see if that works out.
>
> As I had suspected, the main issue is that byte-compilation fails:
> ...
> But I guess this can be resolved upstream, if there is an interest.

The extension packages each require the version of the UI that they work
with. I think it is reasonable to do that, and I don't foresee the other
maintainers wanting to change that.

Is there a way to fix this while still declaring the extension packages'
requirements?

> Other than that, the tarball has a lot of administrative files.  I'd
> recommend adding an .elpaignore:
>

That sounds uncontroversial, so I've applied that change. Thank you for
the recommendation.

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

[Philip Kaludercic]

Okamsn <okamsn@protonmail.com> writes:

> On 2022-12-17 16:24 UTC, Philip Kaludercic wrote:
>> Philip Kaludercic <philipk@posteo.net> writes:
>>
>>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>>
>>>>> The only issue I can think about is if later on someone else wants to
>>>>> add a package that depends on a specific "sub-package", and they find
>>>>> themselves in a conflict specifying their dependency list, in case this
>>>>> hypothetical package is to be distributed both via ELPA and MELPA.
>>>>
>>>> Not our problem?
>>>
>>> So let it be written, so let it be done.
>>>
>>> I will prepare the package with everything bundled into a single
>>> package, and see if that works out.
>>
>> As I had suspected, the main issue is that byte-compilation fails:
>> ...
>> But I guess this can be resolved upstream, if there is an interest.
>
> The extension packages each require the version of the UI that they work
> with. I think it is reasonable to do that, and I don't foresee the other
> maintainers wanting to change that.
>
> Is there a way to fix this while still declaring the extension packages'
> requirements?

In practice, will this be a problem?  As you can see in the -pkg.el
file, so the other packages won't be added to the list by defaut:

--8<---------------cut here---------------start------------->8---
;; Generated package description from prescient.el  -*- no-byte-compile: t -*-
(define-package "prescient" "6.1.0" "Better sorting and filtering" '((emacs "25.1")) :commit nil :authors '(("Radian LLC" . "contact+prescient@radian.codes")) :maintainer '("Radian LLC" . "contact+prescient@radian.codes") :keywords '("extensions") :url "https://github.com/raxod502/prescient.el")
--8<---------------cut here---------------end--------------->8---

If loaded, an error will be raised.

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

[Stefan Monnier]

[-- Attachment #1: Type: text/plain, Size: 664 bytes --]

> Is there a way to fix this while still declaring the extension packages'
> requirements?

Usually the way we expect this to work is:

- the user install prescient
- the user installs company/corfu/younameit
- it just works

Sample (and incomplete) patch below (a lot of it is unrelated,
e.g. I make it use `add-function` instead of manually saving the old
function and restoring it, and I move the "turn off the mode" to the
beginning instead of the weird recursive call which would inevitably
mess up anyone using `<foo>-prescient-mode-hook` as well as confuse
Custom's tracking of whether the mode was set (and whether pragmatically
or not)).


        Stefan

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: prescient.patch --]
[-- Type: text/x-diff, Size: 13075 bytes --]

diff --git a/.gitignore b/.gitignore
index c531d9867f..705768703a 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,5 @@
 *.elc
+
+# ELPA-generated files.
+/prescient-pkg.el
+/prescient-autoloads.el
diff --git a/company-prescient.el b/company-prescient.el
index 5da64dd49e..01915cd9f5 100644
--- a/company-prescient.el
+++ b/company-prescient.el
@@ -26,7 +26,7 @@
 
 ;;;; Libraries
 
-(require 'company)
+(require 'company nil t)
 (require 'prescient)
 
 ;;;; User options
@@ -64,17 +64,19 @@ This is for use on `company-completion-finished-hook'.")
   "Minor mode to use prescient.el in Company completions."
   :global t
   :group 'prescient
-  (if company-prescient-mode
-      (progn
-        (company-prescient-mode -1)
-        (setq company-prescient-mode t)
-        (add-to-list 'company-transformers #'company-prescient-transformer)
-        (add-hook 'company-completion-finished-hook
-                  #'company-prescient-completion-finished))
+  (cond
+   ((boundp 'company-transformers)
     (setq company-transformers
           (delq #'company-prescient-transformer company-transformers))
     (remove-hook 'company-completion-finished-hook
-                 #'company-prescient-completion-finished)))
+                 #'company-prescient-completion-finished)
+    (when company-prescient-mode
+      (add-to-list 'company-transformers #'company-prescient-transformer)
+      (add-hook 'company-completion-finished-hook
+                #'company-prescient-completion-finished)))
+   (t
+    (message "company-prescient-mode: Company not found!")
+    (setq company-prescient-mode nil))))
 
 ;;;; Closing remarks
 
diff --git a/corfu-prescient.el b/corfu-prescient.el
index 3c064d7aee..5bf774d2fc 100644
--- a/corfu-prescient.el
+++ b/corfu-prescient.el
@@ -24,7 +24,10 @@
 ;;;; Libraries and Declarations
 
 (require 'cl-lib)
-(require 'corfu)
+(require 'corfu nil t)
+(defvar corfu--input)
+(defvar corfu--index)
+(defvar corfu--candidates)
 (require 'prescient)
 (require 'subr-x)
 
@@ -38,13 +41,11 @@
 
 (defcustom corfu-prescient-enable-filtering t
   "Whether the `prescient' completion style is used in Corfu."
-  :type 'boolean
-  :group 'corfu-prescient)
+  :type 'boolean)
 
 (defcustom corfu-prescient-enable-sorting t
   "Whether prescient.el sorting is used in Corfu."
-  :type 'boolean
-  :group 'corfu-prescient)
+  :type 'boolean)
 
 (defcustom corfu-prescient-override-sorting nil
   "Whether to force sorting by `corfu-prescient'.
@@ -55,19 +56,16 @@ If non-nil, then `corfu-prescient-mode' sets
 
 Changing this variable will not take effect until
 `corfu-prescient-mode' has been reloaded."
-  :group 'corfu-prescient
   :type 'boolean)
 
 (defcustom corfu-prescient-completion-styles
   prescient--completion-recommended-styles
   "The completion styles used by `corfu-prescient-mode'."
-  :group 'corfu-prescient
   :type '(repeat symbol))
 
 (defcustom corfu-prescient-completion-category-overrides
   prescient--completion-recommended-overrides
   "The completion-category overrides used by `corfu-prescient-mode'."
-  :group 'corfu-prescient
   :type '(repeat (cons symbol (repeat (cons symbol (repeat symbol))))))
 
 ;;;; Toggling Commmands
@@ -80,11 +78,6 @@ by `corfu-prescient-mode'."
     (corfu--update)))
 
 ;;;; Minor mode
-(defvar corfu-prescient--old-sort-function nil
-  "Previous value of `corfu-sort-function'.")
-
-(defvar corfu-prescient--old-sort-override-function nil
-  "Previous value of `corfu-sort-override-function'.")
 
 (defvar corfu-prescient--old-toggle-binding nil
   "Previous binding of `M-s' in `corfu-map'.")
@@ -149,72 +142,18 @@ This mode will:
 - advise `corfu-insert' to remember candidates"
   :global t
   :group 'prescient
-  (if corfu-prescient-mode
-      ;; Turn on the mode.
-      (progn
-        ;; Prevent messing up variables if we explicitly enable the
-        ;; mode when it's already on.
-        (corfu-prescient-mode -1)
-        (setq corfu-prescient-mode t)
-
-        (when corfu-prescient-override-sorting
-          (setq corfu-prescient-enable-sorting t)
-          (cl-shiftf corfu-prescient--old-sort-override-function
-                     corfu-sort-override-function
-                     #'prescient-completion-sort))
-
-        (when corfu-prescient-enable-sorting
-          (cl-shiftf corfu-prescient--old-sort-function
-                     corfu-sort-function
-                     #'prescient-completion-sort))
-
-        (when corfu-prescient-enable-filtering
-          ;; Configure changing settings in the hook.
-          (add-hook 'corfu-mode-hook
-                    #'corfu-prescient--change-completion-settings)
-
-          ;; Immediately apply the settings in buffers where
-          ;; `corfu-mode' is already on.
-          (dolist (b (buffer-list))
-            (when (buffer-local-value corfu-mode b)
-              (with-current-buffer b
-                (corfu-prescient--apply-completion-settings))))
-
-          ;; Bind toggling commands.
-          (setq corfu-prescient--old-toggle-binding
-                (lookup-key corfu-map (kbd "M-s")))
-          (define-key corfu-map (kbd "M-s") prescient-toggle-map)
-
-          ;; Make sure Corfu refreshes immediately.
-          (add-hook 'prescient--toggle-refresh-functions
-                    #'corfu-prescient--toggle-refresh)
-
-          ;; Clean up the local versions of the toggling variables
-          ;; after the Corfu pop-up closes. For the toggling vars, it
-          ;; is the commands themselves that make the variables buffer
-          ;; local.
-          (cl-callf cl-union corfu--state-vars prescient--toggle-vars
-                    :test #'eq))
-
-        ;; While sorting might not be enabled in Corfu, it might
-        ;; still be enabled in another UI, such as Selectrum or Vertico.
-        ;; Therefore, we still want to remember candidates.
-        (advice-add 'corfu--insert :before #'corfu-prescient--remember))
-
-    ;; Turn off mode.
 
+  (cond
+   ((boundp 'corfu-map)
     ;; Undo sorting settings.
-    (when (eq corfu-sort-function #'prescient-completion-sort)
-      (setq corfu-sort-function corfu-prescient--old-sort-function))
-    (when (eq corfu-sort-override-function #'prescient-completion-sort)
-      (setq corfu-sort-override-function
-            corfu-prescient--old-sort-override-function))
+    (remove-function corfu-sort-function #'prescient-completion-sort)
+    (remove-function corfu-sort-override-function #'prescient-completion-sort)
 
     ;; Unbind toggling commands and unhook refresh function.
     (when (equal (lookup-key corfu-map (kbd "M-s"))
                  prescient-toggle-map)
       (define-key corfu-map (kbd "M-s")
-        corfu-prescient--old-toggle-binding))
+                  corfu-prescient--old-toggle-binding))
     (remove-hook 'prescient--toggle-refresh-functions
                  #'corfu-prescient--toggle-refresh)
     (cl-callf cl-set-difference corfu--state-vars
@@ -230,7 +169,55 @@ This mode will:
           (corfu-prescient--undo-completion-settings))))
 
     ;; Undo remembrance settings.
-    (advice-remove 'corfu-insert #'corfu-prescient--remember)))
+    (advice-remove 'corfu-insert #'corfu-prescient--remember)
+
+    (when corfu-prescient-mode
+      ;; Turn on the mode.
+      (when corfu-prescient-override-sorting
+        (setq corfu-prescient-enable-sorting t)
+        (add-function :override corfu-sort-override-function
+                      #'prescient-completion-sort))
+
+      (when corfu-prescient-enable-sorting
+        (add-function :override corfu-sort-function
+                      #'prescient-completion-sort))
+
+      (when corfu-prescient-enable-filtering
+        ;; Configure changing settings in the hook.
+        (add-hook 'corfu-mode-hook
+                  #'corfu-prescient--change-completion-settings)
+
+        ;; Immediately apply the settings in buffers where
+        ;; `corfu-mode' is already on.
+        (dolist (b (buffer-list))
+          (when (buffer-local-value corfu-mode b)
+            (with-current-buffer b
+              (corfu-prescient--apply-completion-settings))))
+
+        ;; Bind toggling commands.
+        (setq corfu-prescient--old-toggle-binding
+              (lookup-key corfu-map (kbd "M-s")))
+        (define-key corfu-map (kbd "M-s") prescient-toggle-map)
+
+        ;; Make sure Corfu refreshes immediately.
+        (add-hook 'prescient--toggle-refresh-functions
+                  #'corfu-prescient--toggle-refresh)
+
+        ;; Clean up the local versions of the toggling variables
+        ;; after the Corfu pop-up closes. For the toggling vars, it
+        ;; is the commands themselves that make the variables buffer
+        ;; local.
+        (cl-callf cl-union corfu--state-vars prescient--toggle-vars
+                  :test #'eq))
+
+      ;; While sorting might not be enabled in Corfu, it might
+      ;; still be enabled in another UI, such as Selectrum or Vertico.
+      ;; Therefore, we still want to remember candidates.
+      (advice-add 'corfu--insert :before #'corfu-prescient--remember)))
+   (t
+    (message "corfu-prescient-mode: Corfu not found!")
+    (setq corfu-prescient-mode nil))))
+
 
 (provide 'corfu-prescient)
 ;;; corfu-prescient.el ends here
diff --git a/selectrum-prescient.el b/selectrum-prescient.el
index dd645e1272..07caaeb3d4 100644
--- a/selectrum-prescient.el
+++ b/selectrum-prescient.el
@@ -24,7 +24,8 @@
 ;;;; Libraries
 
 (require 'prescient)
-(require 'selectrum)
+(require 'selectrum nil t)
+(defvar selectrum-refine-candidates-function)
 (require 'subr-x)
 
 ;;;; Customization
@@ -42,7 +43,6 @@ filtering behavior of Selectrum from the default. See Selectrum
 documentation for how to configure filtering yourself. Changing
 this variable will not take effect until
 `selectrum-prescient-mode' has been reloaded."
-  :group 'selectrum-prescient
   :type 'boolean)
 
 (defcustom selectrum-prescient-enable-sorting t
@@ -52,7 +52,6 @@ sorting behavior of Selectrum from the default. See Selectrum
 documentation for how to configure sorting yourself. Changing
 this variable will not take effect until
 `selectrum-prescient-mode' has been reloaded."
-  :group 'selectrum-prescient
   :type 'boolean)
 
 ;;;; Toggling commands
@@ -98,17 +97,11 @@ matches first."
 (defvar selectrum-prescient--old-preprocess-function nil
   "Previous value of `selectrum-preprocess-candidates-function'.")
 
-(defvar selectrum-prescient--old-refine-function nil
-  "Previous value of `selectrum-refine-candidates-function'.")
-
 (defun selectrum-prescient--remember (candidate &rest _)
   "Remember CANDIDATE in prescient.el.
 For use on `selectrum-candidate-selected-hook'."
   (prescient-remember candidate))
 
-(defvar selectrum-prescient--old-highlight-function nil
-  "Previous value of `selectrum-highlight-candidates-function'.")
-
 ;;;###autoload
 (define-minor-mode selectrum-prescient-mode
   "Minor mode to use prescient.el in Selectrum menus."
@@ -121,14 +114,10 @@ For use on `selectrum-candidate-selected-hook'."
         (selectrum-prescient-mode -1)
         (setq selectrum-prescient-mode t)
         (when selectrum-prescient-enable-filtering
-          (setq selectrum-prescient--old-refine-function
-                selectrum-refine-candidates-function)
-          (setq selectrum-prescient--old-highlight-function
-                selectrum-highlight-candidates-function)
-          (setq selectrum-refine-candidates-function
-                #'selectrum-prescient--refine)
-          (setq selectrum-highlight-candidates-function
-                #'prescient--highlight-matches)
+          (add-function :override selectrum-refine-candidates-function
+                        #'selectrum-prescient--refine)
+          (add-function :override selectrum-highlight-candidates-function
+                        #'prescient--highlight-matches)
           (define-key selectrum-minibuffer-map
             (kbd "M-s") prescient-toggle-map)
           (add-hook 'prescient--toggle-refresh-functions
@@ -142,14 +131,10 @@ For use on `selectrum-candidate-selected-hook'."
                     #'selectrum-prescient--remember)
           (add-hook 'selectrum-candidate-inserted-hook
                     #'selectrum-prescient--remember)))
-    (when (eq selectrum-refine-candidates-function
-              #'selectrum-prescient--refine)
-      (setq selectrum-refine-candidates-function
-            selectrum-prescient--old-refine-function))
-    (when (eq selectrum-highlight-candidates-function
-              #'prescient--highlight-matches)
-      (setq selectrum-highlight-candidates-function
-            selectrum-prescient--old-highlight-function))
+    (remove-function selectrum-refine-candidates-function
+                     #'selectrum-prescient--refine)
+    (remove-function selectrum-highlight-candidates-function
+                     #'prescient--highlight-matches)
     (when (equal (lookup-key selectrum-minibuffer-map (kbd "M-s"))
                  prescient-toggle-map)
       (define-key selectrum-minibuffer-map (kbd "M-s") nil))

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

[Okamsn]

On 2022-12-17 18:39 UTC, Stefan Monnier wrote:
>> Is there a way to fix this while still declaring the extension packages'
>> requirements?
>
> Usually the way we expect this to work is:
>
> - the user install prescient
> - the user installs company/corfu/younameit
> - it just works
>
> Sample (and incomplete) patch below (a lot of it is unrelated,
> e.g. I make it use `add-function` instead of manually saving the old
> function and restoring it, and I move the "turn off the mode" to the
> beginning instead of the weird recursive call which would inevitably
> mess up anyone using `<foo>-prescient-mode-hook` as well as confuse
> Custom's tracking of whether the mode was set (and whether pragmatically
> or not)).
>
>
>          Stefan

OK, I misunderstood what was being said about `require`. I will make
that change.

Would you please explain why one would want to use `add-function`
instead of directly setting `corfu-sort-function`, since setting the
variable is the intended use? Do you think that storing the old value is
insufficient?

Also, you suggest using `message` to warn that `corfu` isn't found.
Would use of the function `user-error` be incorrect for this?

Thank you.

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

[Stefan Monnier]

> Would you please explain why one would want to use `add-function`
> instead of directly setting `corfu-sort-function`, since setting the
> variable is the intended use? Do you think that storing the old value is
> insufficient?

Two main reasons:
- It's simpler (less code).
- It has a chance of working correctly if some other package also comes
  and installs its own function there.

> Also, you suggest using `message` to warn that `corfu` isn't found.
> Would use of the function `user-error` be incorrect for this?

Either way seems fine.


        Stefan

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

[Okamsn]

On 2022-11-20 09:24 UTC, Philip Kaludercic wrote:
> Okamsn <okamsn@protonmail.com> writes:
>
>> Hello,
>
> Hi,
>
>> Would you be willing to add Prescient[1] and some of its related
>> packages to NonGNU ELPA, as in the attached file? I am one of the
>> maintainers of this package. The author of the package does not wish to
>> assign copyright or require others to do so, so it cannot be added to
>> GNU ELPA.
>>
>> Prescient is for sorting and filtering completion candidates. Its
>> filtering is similar to the package Orderless and it sorts by a
>> combination of the frequency and the recency of the candidates.
>
>  From what I recall, Vertico does that too, but Vertico is a completion
> front-end?  Intuitively I would have also guessed that the front-end is
> the right place to solve this problem.
>
> Or maybe to rephrase the question, what does this package provide over
> vertico + orderless?

With Vertico's default sorting, the recency is unique to each command.
Prescient remembers the selected candidates for all completion commands,
using their recency and frequency to create a ranking of that candidate
for all commands in which they're shown.

With Prescient, one can select a candidate in one command and have it be
suggested for another command, such as inserting a candidate with
Company and later having it suggested near the top of the list when
calling `describe-variable` in Vertico. Candidates that are used more
frequently are ranked higher. If candidates haven't been used recently,
they eventually have their rankings forgotten.

There are other smaller differences, such as that, because Prescient can
provide both sorting and filtering, it can sort fully matched candidates
before partially matched candidates.

>
>> These are the packages I am wondering if you would be willing to add:
>>
>> - `prescient`: The base package, which provides the sorting and
>>      filtering functions and a completion style
>>
>> - `company-prescient`: Use `prescient` sorting with Company
>>
>> - `corfu-prescient`: Use `prescient` sorting and filtering with Corfu
>>
>> - `vertico-prescient`: Use `prescient` sorting and filtering with Vertico
>
> Could you explain the need for these other packages?  If we are talking
> about a completion style, why do other packages require their own
> support?

Prescient does not provide a completion UI.  Instead, there are packages
to set it up for completion UIs. It is not just a completion style
(which was only added recently, years after the filtering functions). To
use the sorting, one must also configure their chosen UI and set up a
way to make Prescient remember the selected candidate. The packages set
up this sorting in addition to the filtering.

I tried using modification of the completion metadata for sorting,
similar to the `flex` style, but it was decided that it is better to
keep the filtering and sorting more separate.  For example, to still be
able to sort the candidates filtered by other completion styles.

Because the integrations are UI specific, they are kept as separate
packages.

>
>> 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?

For the development/main version in the "main" branch, I don't want to
change how the author has set up the repository, since they still use it.

In this setup, the `:branch` property would be "main" and the
`:release-branch` property would be something like
"nongnu-elpa/prescient", yes?

Is the GNU ELPA README stating that it wants the version number to be
updated during every commit in the development branch? In that case,
maybe I could find a way to make GitHub update the development version
number in a separate branch.

>> 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.

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

[Okamsn]

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

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?

>>> 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.

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

[Stefan Monnier]

> 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?

`load-path` is a list of directories, so you can only control which
files are included by controlling which directories are included.

But I don't understand the question coming from you: as a developer of
the package, how do *you* control that (since, presumably, you use that
same file layout as used in the Git repository)?


        Stefan

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

[Okamsn]

On 2022-12-05 15:21 UTC, Stefan Monnier wrote:
>> 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?
>
> `load-path` is a list of directories, so you can only control which
> files are included by controlling which directories are included.
>
> But I don't understand the question coming from you: as a developer of
> the package, how do *you* control that (since, presumably, you use that
> same file layout as used in the Git repository)?
>
>
>          Stefan
>

If you are asking whether I add the Git repository itself to the load
path for testing packages, I do not. Instead, I have been using
Straight.el (https://github.com/radian-software/straight.el) to install
development versions of packages, which can download the repository once
but only install the files and needed dependencies (according to a
specification) by linking/copying those compiled files to another
directory, which is then added to the load path.

For Prescient in particular, it makes sense to have the files in a
single repository, since a change in the main file can mean changes in
the extension files and vice versa (as a single conceptual step in
development). However, testing the development version of an extension
for one UI (such as for Vertico) doesn't necessarily mean wanting to use
the development version of another UI's extension (such as for Company)
or wanting to install another extension's dependee UI package (such as
Selectrum, which was soft-deprecated in favor of Vertico).

Is this what you are asking?

Really, I was wanting to ask whether package-vc installs all of the
ELisp files in a repository or whether it installs the files according
to the ELPA spec or a provided spec. I see that the user option
`package-vc-selected-packages` does not mention the `:ignored-files`
entry that the ELPA spec uses, so I was wondering.

The documentation string for `package-vc-checkout` mentions a
`package-vc-link-directory`, but I don't see that in the file. Did that
become `package-vc-install-from-checkout`?

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

[Stefan Monnier]

> If you are asking whether I add the Git repository itself to the load
> path for testing packages, I do not. Instead, I have been using
> Straight.el (https://github.com/radian-software/straight.el) to install
> development versions of packages, which can download the repository once
> but only install the files and needed dependencies (according to a
> specification) by linking/copying those compiled files to another
> directory, which is then added to the load path.

Ah, so `straight` relies on linking/copying the files.
Do things like `C-h f` still jump to the actual VCS-controlled source?

How does it make sure the copies are updated/sync'd when you edit the
VCS-controlled sources?

> For Prescient in particular, it makes sense to have the files in a
> single repository, since a change in the main file can mean changes in
> the extension files and vice versa (as a single conceptual step in
> development). However, testing the development version of an extension
> for one UI (such as for Vertico) doesn't necessarily mean wanting to use
> the development version of another UI's extension (such as for Company)
> or wanting to install another extension's dependee UI package (such as
> Selectrum, which was soft-deprecated in favor of Vertico).

I think in the context of `package-vc` the cleanest way to support some
of that would be to require that the different subpackages's files live
in different subdirectories of the repository (so we can add/remove them
from `load-path` independently).

[ I also note a tension here: on the one hand you say that the
  development is sufficiently tightly linked that you may want to change
  several subpackages in a single commit , but on the other you want to
  be able to use different versions of different subpackages at the same
  time which requires a looser coupling.  ]

> Is this what you are asking?

Yes, exactly, thank you.

> Really, I was wanting to ask whether package-vc installs all of the
> ELisp files in a repository or whether it installs the files according

It does a `git clone`, creates the *-pkg.el and *-autoloads.el files,
compiles the files and adds them to `load-path`.  So you run your code
straight :-) from the VCS clone.

> to the ELPA spec or a provided spec. I see that the user option
> `package-vc-selected-packages` does not mention the `:ignored-files`
> entry that the ELPA spec uses, so I was wondering.

Indeed, it does not support things like `:ignored-files` or
`.elpaignore` or `:renames`.


        Stefan

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

[Philip Kaludercic]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> to the ELPA spec or a provided spec. I see that the user option
>> `package-vc-selected-packages` does not mention the `:ignored-files`
>> entry that the ELPA spec uses, so I was wondering.
>
> Indeed, it does not support things like `:ignored-files` or
> `.elpaignore` or `:renames`.

One caveat: Along with package-vc.el, package.el coincidentally learned
how to use ".elpaignore" files, but these are only used to suppress
byte-compilation.

elpa-admin.el uses .elpaignore and :ignored-files to exclude files from
the final tarball, but this concept isn't applicable to source packages.

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

[Richard Kim]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Ah, so `straight` relies on linking/copying the files.
> Do things like `C-h f` still jump to the actual VCS-controlled source?
>
> How does it make sure the copies are updated/sync'd when you edit the
> VCS-controlled sources?

As far as I know straight does not do any copying at least not *.el
files. It creates symlinks to *.el and other files so that `C-h f' jumps
to VCS-controlled source. Following is how straight installs use-package
to a directory which is added to load-path and Info-directory-list. The
"install" directories are distinct from git repos. It shows that all
*.el are symlinks to the git repo. All files that are not symlinks are
generated files.


$ file * | head -5
dir:                      data
use-package-autoloads.el: Lisp/Scheme program, ASCII text
use-package-bind-key.el:  symbolic link to /home/kimr/.emacs.d/sm-ms/.local/straight/repos/use-package/use-package-bind-key.el
use-package-bind-key.elc: Emacs/XEmacs v28 byte-compiled Lisp data
use-package-core.el:      symbolic link to /home/kimr/.emacs.d/sm-ms/.local/straight/repos/use-package/use-package-core.el


Another example is magit shown below. Note that *.el files are located
in "lisp" sub-directory of the git repo. If I understood package-vc
correctly, it requires :lisp-dir to be set correctly for packages such
as magit which house lisp files in sub-directories. straight.el places
all *.el symlinks in the top level directory where packages are
installed.


$ file * | head -7
AUTHORS.md:                symbolic link to /home/kimr/.emacs.d/sm-ms/.local/straight/repos/magit/docs/AUTHORS.md
dir:                       data
git-rebase.el:             symbolic link to /home/kimr/.emacs.d/sm-ms/.local/straight/repos/magit/lisp/git-rebase.el
git-rebase.elc:            Emacs/XEmacs v28 byte-compiled Lisp data
LICENSE:                   symbolic link to /home/kimr/.emacs.d/sm-ms/.local/straight/repos/magit/LICENSE
magit-apply.el:            symbolic link to /home/kimr/.emacs.d/sm-ms/.local/straight/repos/magit/lisp/magit-apply.el
magit-apply.elc:           Emacs/XEmacs v28 byte-compiled Lisp data


https://github.com:emacs18/spacemacs is my fork of spacemacs. The branch
named sm-straight modifies spacemacs to use straight.el rather than
package.el. I've been using this for quite some time.

I'm curious whether I can share all my git clones of emacs packages for
both straight.el and package-vc.  I'll probably git this a shot soon.

Also a while ago I converted two more emacs setups to use straight.el
rather than package.el although I have not used either of these in a
while.

https://github.com/emacs18/purcell.git is a fork of
https://github.com/purcell/emacs.d. Branch named 'straight' uses
straight.el instead of package.el.

https://github.com/emacs18/scimax.git is a fork of
https://github.com/jkitchin/scimax.  Branch named 'straight' uses
straight.el instead of package.el

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

[Stefan Monnier]

>> Ah, so `straight` relies on linking/copying the files.
>> Do things like `C-h f` still jump to the actual VCS-controlled source?
>>
>> How does it make sure the copies are updated/sync'd when you edit the
>> VCS-controlled sources?
>
> As far as I know straight does not do any copying at least not *.el
> files.  It creates symlinks to *.el and other files so that `C-h f' jumps

I see.  So Straight doesn't work under Windows?  Or does it then use
copying (and `C-h f` doesn't jump to the source any more)?


        Stefan

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

[Richard Kim]

I have not used Windows for so long that I hardly know anything about
it.  However following is found on straight.el documentation:

On Microsoft Windows, however, support for symlinks is not always
available, so the default value of straight-use-symlinks is nil on
that platform. That causes copying to be used instead, and an advice
is placed on find-file to cause the copied files to act as symlinks if
you try to edit them.

On Sat, 10 Dec 2022 at 07:12, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>
> >> Ah, so `straight` relies on linking/copying the files.
> >> Do things like `C-h f` still jump to the actual VCS-controlled source?
> >>
> >> How does it make sure the copies are updated/sync'd when you edit the
> >> VCS-controlled sources?
> >
> > As far as I know straight does not do any copying at least not *.el
> > files.  It creates symlinks to *.el and other files so that `C-h f' jumps
>
> I see.  So Straight doesn't work under Windows?  Or does it then use
> copying (and `C-h f` doesn't jump to the source any more)?
>
>
>         Stefan
>

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

[Stefan Monnier]

> available, so the default value of straight-use-symlinks is nil on
> that platform.  That causes copying to be used instead, and an advice
> is placed on find-file to cause the copied files to act as symlinks if
> you try to edit them.

Ah, I see.  I'm not too keen on hooking directly into find-file, but
I guess the `find-library` could be tweaked, indeed.

Still.  I much prefer the model of "one package per directory"
which doesn't require such contortions.


        Stefan

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+

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

[Okamsn]

[-- Attachment #1: Type: text/plain, Size: 1046 bytes --]

On 2022-12-05 17:21 UTC, Philip Kaludercic wrote:
>>>>> 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+

I have updated the files version number. The packages install
successfully from the built tar files. Are there other steps to perform?

I've reattached the patch to this message.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: second-attempt.patch --]
[-- Type: text/x-patch; name=second-attempt.patch, Size: 2193 bytes --]

diff --git a/elpa-packages b/elpa-packages
index 8254411cb2..1e91d9d4c2 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -593,6 +593,46 @@
  (popup			:url "https://github.com/auto-complete/popup-el"
   :ignored-files ("LICENSE"))
 
+ ("prescient"           :url "https://github.com/radian-software/prescient.el"
+  :branch "main"
+  :news "CHANGELOG.md"
+  :mainfile "prescient.el"
+  :readme "README.md"
+  :ignored-files ("Dockerfile" "LICENSE.md" "Makefile" "company-prescient.el"
+                  "corfu-prescient.el" "ivy-prescient.el" "scripts"
+                  "selectrum-prescient.el" "stub" "vertico-prescient.el"
+                  ".dir-locals.el" ".github" ".gitignore"))
+
+ ("vertico-prescient"   :url "https://github.com/radian-software/prescient.el"
+  :branch "main"
+  :news "CHANGELOG.md"
+  :mainfile "vertico-prescient.el"
+  :readme "README.md"
+  :ignored-files ("Dockerfile" "LICENSE.md" "Makefile" "company-prescient.el"
+                  "corfu-prescient.el" "ivy-prescient.el" "prescient.el"
+                  "scripts" "selectrum-prescient.el" "stub" ".dir-locals.el"
+                  ".github" ".gitignore"))
+
+ ("corfu-prescient"     :url "https://github.com/radian-software/prescient.el"
+  :branch "main"
+  :news "CHANGELOG.md"
+  :mainfile "corfu-prescient.el"
+  :readme "README.md"
+  :ignored-files ("Dockerfile" "LICENSE.md" "Makefile" "company-prescient.el"
+                  "ivy-prescient.el" "prescient.el" "scripts"
+                  "selectrum-prescient.el" "stub" "vertico-prescient.el"
+                  ".dir-locals.el" ".github" ".gitignore"))
+
+ ("company-prescient"   :url "https://github.com/radian-software/prescient.el"
+  :branch "main"
+  :news "CHANGELOG.md"
+  :mainfile "company-prescient.el"
+  :readme "README.md"
+  :ignored-files ("Dockerfile" "LICENSE.md" "Makefile" "corfu-prescient.el"
+                  "ivy-prescient.el" "prescient.el" "scripts"
+                  "selectrum-prescient.el" "stub" "vertico-prescient.el"
+                  ".dir-locals.el" ".github" ".gitignore"))
+
  (projectile		:url "https://github.com/bbatsov/projectile"
   :ignored-files ("LICENSE" "doc" "test")
   :news "CHANGELOG.md")

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

[Philip Kaludercic]

Okamsn <okamsn@protonmail.com> writes:

> On 2022-12-05 17:21 UTC, Philip Kaludercic wrote:
>>>>>> 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+
>
> I have updated the files version number. The packages install
> successfully from the built tar files. Are there other steps to perform?
>
> I've reattached the patch to this message.

Unless there are any outstanding issues, and nothing more to discuss, I
guess the package can be added.

Just to make sure, as it was mentioned in another message:  Bundling
everything in a single package is not an option?

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

[Jonas Bernoulli]

Philip Kaludercic <philipk@posteo.net> writes:

>> 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.

When making such requests, we should think about the needs of all
involved parties.  We all have our own ideas of "best practices"
and sometimes these ideas are in conflict with each other and/or
convenience.

For the maintainers of a "main package" with "extension packages", it is
most convenient to keep these packages in a single repository; making
changes across more than one of the packages is easier that way.  Since
they work on these packages the most, their needs should come first, and
as far as I can tell, nobody tries to *force* them to do something else.

For most users it doesn't matter much.  [Non]GNU Elpa and Melpa take
care of distributing the extension packages separately, making sure that
users do not have to install any additional packages, which are only
needed by one of the extensions, unless they actually want to use those.

For Melpa it is trivial to split a repository into multiple packages.

[Non]GNU Elpa take a different approach when it comes to deciding which
files to include in package tarballs.  Where Melpa excludes everything
except certain files, [Non]GNU Elpa include everything except certain
files.  (I might be wrong about this, but I believe) [Non]GNU Elpa do
not have a default exclude list used for all packages.  As a
consequence, and even though they include more files, I believe their
file specifications tend to be more verbose.  [I don't intend to argue
here for one approach or the other, that isn't the question here.]

People involved in [Non]GNU Elpa pushing back harder against putting
extensions in the same repository as the main package than the Melpa
folks, is probably an indicator that dealing with such bundling is more
work for them.

But AFAIK it cannot be *that* much more work, that it would justify by
itself, to ask package maintainers to take on even more additional work
by splitting up their repositories, and to implying in those requests
that doing so is a best practice that will benefit everyone.

If package maintainers are willing to split up their repositories, even
though it means more work for them, that is fine by me.  (Here too, it
isn't *that* much additional work, and I agree that if we all had
infinite time, this clearly would be the best way of doing it.)  But I
don't think splitting things up to the extreme should be described as an
unquestionable best practice; after all emacs.git itself bundles a lot
of unrelated packages in the same repository.  [Off topic and maybe a
bit surprising: I would be in favor of splitting up emacs.git more, but
let's not get into that here.]

I should note that I am aware that the work is not done by once writing
the file include/exclude rules when the multiple packages that are
maintained in a single repository are first added.  The later addition
of yet another library/package can make it necessary to adjust those
existing rules.  But I don't think this is a huge burden and that it is
small compared to the additional work that you are asking package
maintainers to take on by splitting up their repositories.

Another drawback of main+extension repositories from the perspective of
[Non]GNU Elpa is that it makes it necessary for elpa-admin.el to
checkout the same repository multiple times.  I think this is a small
drawback and I would recommend that just ignore it.  Otherwise it is an
internal tooling issue that shouldn't concern package maintainers;
elpa-admin.el could, for example, be taught to clone the repository just
once and to use a separate worktree for each package.

Moving to another interested party, the Emacsmirror, which I maintain.
The Emacsmirror provides a superset of the packages in any one of the
elpas, or all elpas taken together for that matter.  A consequence of
that is that it has to deal with a lot more diverging practices, and
that the various elpas promote in some cases competing best practices.

Also, because the benefits of the Emacsmirror are less obvious I am in
a weaker position when requesting changes from packages maintainers,
compared to people maintaining an elpa.  But since we are nevertheless
in a similar boat, I appreciate it, when the maintainers of the elpas
take the needs of the Emacsmirror into account.

The Emacsmirror itself does not even attempt splitting up repositories
that contain multiple packages.  It mirrors repositories.  Ideally one
repository contains one package, but that isn't always the case and
trying to change it would be an uphill battle, which could never be won.
I have been fighting some other uphill battles for years, but ultimately
I often have no choice but to accept that package maintainers do things
that I think are not ideal or even wrong.

Nowadays, for the most part, the Emacsmirror learns about new packages
to mirror, by importing the lists of package recipes/specifications of
the various elpas.  Because the elpas do sometimes build multiple
packages from a single repository, duplicates appear in those lists
(from the mirror's perspective) and I have to make sure to not add the
same repository twice.

This is where this recommendation becomes problematic:

> E.g. by making each project live on it's own branch.

The current Emacsmirror code cannot deal with this special case.  It
wouldn't be hard to support it, but so far I had no reason to implement
that.  There is *a single* package that currently does this (as a result
of Stefan Monnier asking its maintainer to do so).

The Straight package manager apparently cannot deal with this either.  I
would assume that it wouldn't be hard to implement support, but here too
it does not make much sense to do so for the benefit of a single package
that wants to do things differently.

My own package manager, Borg, follows the lead of the Emacsmirror.  It
clones the main-package+extensions repository as-is.  Users have to
explicitly exclude the extensions that they are not interested in, or
they get compilation errors.  This might sound not very user-friendly to
those who don't use Borg, but in practice it works well; Borg is just
more picky about who its friends are (but that isn't the topic here).

As I have said before, I agree that ideally extensions to a main package
would be maintained in separate repositories, but also that this means
more work for the maintainers, and if they don't want to do it because
of that, then that should be accepted.

I have one additional request: When you encourage package maintainers to
split up their repositories, then do NOT recommend that they put the
separate packages into separate branches of the SAME repository.

Instead ask them to use separate repositories altogether.  Except for
the small additional initial need to create the separate repositories,
this should not be any more work than using merely separate branches.

Merely using separate branches is a half measure, that doesn't really
benefit anyone.  Various tools that deal with emacs packages currently
don't support it.  Setting up the branches requires knowing or learning
about orphan branches.  Checking out multiple packages requires either
cloning the same repository multiple times, or knowing or learning how
to use multiple worktrees.

     Jonas

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

[Stefan Monnier]

> Another drawback of main+extension repositories from the perspective of
> [Non]GNU Elpa is that it makes it necessary for elpa-admin.el to
> checkout the same repository multiple times.  I think this is a small
> drawback and I would recommend that just ignore it.  Otherwise it is an
> internal tooling issue that shouldn't concern package maintainers;
> elpa-admin.el could, for example, be taught to clone the repository just
> once and to use a separate worktree for each package.

Agreed.

The real reason behind the pushback is when trying to support "install
from VCS", such as `package-vc` (which is also supported by
`elpa-admin.el`, tho in less user-friendly way).

E.g. I can't see a clean way to install `git-commit` directly from its
VCS (i.e. recognized by `package-activate-all` and running from the Git
clone) without either forcing the install of `magit` at the same
time(&place) and/or having side-effects like sometimes shadowing another
installation of `magit`.

We may be able to handle it satisfactorily *if* the various subpackages
are each placed in a different subdirectory (and indeed, in that case,
depending on the VCS we may even be able to clone only the relevant
subdir (or maybe clone the whole, but make a worktree that only exposes
the relevant subdir)).


        Stefan "I care about that because that's the way I've installed
                all my packages for the last few years and I find it very
                convenient :-)"

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

[Jonas Bernoulli]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> E.g. I can't see a clean way to install `git-commit` directly from its
> VCS (i.e. recognized by `package-activate-all` and running from the Git
> clone) without either forcing the install of `magit` at the same
> time(&place) and/or having side-effects like sometimes shadowing another
> installation of `magit`.

I see what you did there. ;)

This is an unusual, and in a sense extreme, example.  Prescient is a
much more typical example, so if you want to discuss the negative effect
that such practices have on your workflow, then it would be better to
focus on that package.

git-commit/magit also has an unpleasant backstory.  I can tell you about
that in a private message.  All I'll say here is that I did not actually
want to add git-commit to magit but the behavior of its author forced me
to accept the offer to take over as maintainer.  At the time it seemed
best to do that by adding it to the magit repository.

Moving it to a separate repository is an option.

At this time there aren't many changes that touch it, as well as other
parts of the repository, so the cost would probably be pretty low, and
I have done the same for with-editor and magit-popup (now replaced by
transient) before.

On the other hand, I have some doubts this is actually going to benefit
anyone.  Is there anyone out there who does use git-commit but not
magit?

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

[Stefan Monnier]

>> E.g. I can't see a clean way to install `git-commit` directly from its
>> VCS (i.e. recognized by `package-activate-all` and running from the Git
>> clone) without either forcing the install of `magit` at the same
>> time(&place) and/or having side-effects like sometimes shadowing another
>> installation of `magit`.
[...]
> This is an unusual, and in a sense extreme, example.

FWIW, I have no idea whether it's usual or not and what's its history.

> Prescient is a much more typical example,

I don't know in which way the situation is different for Prescient.

> git-commit/magit also has an unpleasant backstory.  I can tell you about
> that in a private message.  All I'll say here is that I did not actually
> want to add git-commit to magit but the behavior of its author forced me
> to accept the offer to take over as maintainer.  At the time it seemed
> best to do that by adding it to the magit repository.

But that makes no difference to the problem at hand: by being in the
same directory as the other `magit` files, you can't add it to
`load-path` without adding those other files as well.

> On the other hand, I have some doubts this is actually going to benefit
> anyone.  Is there anyone out there who does use git-commit but not magit?

This cuts both ways: if they're always installed in pair, why not keep
them as a single package?


        Stefan