Re: Automatic Suggestion of Packages

[Philip Kaludercic <philipk@posteo.net>]

Mekeor Melire <mekeor@posteo.de> writes:

> Thanks, Philip, for working on this feature.
>
> As far as I can tell, your code is based on this workflow: Emacs
> maintainers regularly locally build GNU Elpa as well as NonGNU
> Elpa. They run the admin/scrape-elpa.el script which updates the
> package-autosuggest.eld file that is part of the Emacs Git
> repository. They review the changes and commit them.

Right.

> This has some disadvantages: It is quiet some work for the core Emacs
> maintainers: They need to judge if a package is a valid package for a
> certain file. 

This is true, but it would usually be the ELPA maintainers that update
package-autosuggest.eld anyway, and I hope it should be manageable to
just review the diff.

>               Only GNU and NonGNU Elpa packages are respected; other
> package archives are not. Changes to the package-autosuggest.eld file
> would not reach end-users until another Emacs release.

These are valid points, though not unsubstantiated.  Restricting the
packages to {,Non}GNU ELPA is intentional, as all users should have
these archives configured (unless they intentionally disabled them,
which is unusual AFAIK).  These packages should also align with Emacs
free-software policy, to ensure that a upfront suggestion to install a
package respects user-freedom.

That being said, there have been discussions to update the
package.el-API (the "archive-contents" file), in which case we could
consider providing package suggestions.  In that case I would like to
add an option to filter what archives are allowed to make suggestions
(following the above logic, this would be set to the ELPAs by default,
but the user could add personal or third-party if they wish to the
list).

> More generally, I have the impression that this is not the right place
> to implement this feature. I think every package should be able to
> suggest itself for certain file extensions (or even file beginnings or
> endings like magic-mode-alist). I suggest to introduce a new package
> header similar to these:
>
> ;; Covered-File-Extensions: ("\\.c$" "\\.h$")
> ;; Covered-Magic-Beginnings: ("^#!/bin/sh")
>
> These headers would become part of the package structure and would be
> distributed by package archives and would end on the end-users' local
> device. In particular, if you have Melpa set up locally, you would be
> able to find out which Melpa-packages cover .c extensions by filtering
> your local package list accordingly.
>
> This, of course, is much more work; but it seems to be the right thing
> to do, to me. What do you think?

The main issue is that we wouldn't have anything to work with right
away.  We could consider this in the future (along with the updated API
idea, where archives could decide on how to implement this on their
own), but my question is wouldn't these archives coincide with
autoloaded `add-to-list' expressions?  When would a package hint that it
could be useful for .foo-files, but not update `auto-mode-alist'?

The headers might be interesting to hint different priorities, so as to
differentiate between something as foundational as a major mode and
something nice-to-have like a minor-mode or a set of commands.

-- 
	Philip Kaludercic on siskin