Re: Easy configuration of a site-lisp directory

[Arthur Miller]

Philip Kaludercic <philipk@posteo.net> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> Philip Kaludercic [2021-08-25 11:13:49] wrote:
>>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>>> Max Brieiev [2021-08-23 12:14:46] wrote:
>>>>> So is there any conclusion in this long thread about preferable setup
>>>>> for the case described in the original post?  And making local git
>>>>> repositeries be package.el aware.
>>>>
>>>> From my point of view, the "preferable setup" is for someone to spice up
>>>> `elpa-admin.el` to make it more user-friendly for that use-case.
>>>
>>> I could look into this, because I was intending to work on elpa-admin.el
>>> a bit anyway.  But this would mean that it wouldn't work OOTB, right?
>>
>> Not sure what you mean by that, but I'm pretty sure the answer is no.
>
> My suggestion to add something like site-lisp.el to Emacs itself was to
> allow anyone to use unpackaged elisp code on their local system, without
> having to manually bother with updating load-path and autoloading.

If I continue from previous response to you: yes, it was clear what you
meant and problem is as I described there. Your proposal is good for you who are
experienced with working with Emacs Lisp, but lot's of people aren't and that
could potentially lead to other problems for them.

But what about attacking the problem from the other side: requirement for a
package to be installable seems to be very minimal. Only thing I needed to add
to my own was to put a comment with a version number. We could hack package.el
to remove that requirement, or to add a version number automatically, that would
made pretty much any code package installable.

The problem which can't be solved automatically is to figure out all the 
possible
requirements. Somebody has to manually add a comment with requirements in the
code, that in proper format. Which isn't hard to do but still has to be done. I
don't know what is best practice there, but I don't think it is possible to do
much than to simply warn the user that dependencies are potentially missing.

Best would be if package authors were aware of this themselves and added version
number and requirements in proper format. Then their code would be auto
installable via package manager even if it is not in some official repository.