Re: Easy configuration of a site-lisp directory

[Stefan Monnier <monnier@iro.umontreal.ca>]

Philip Kaludercic [2021-08-25 14:55:20] wrote:
> 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.

Right, and the approach I use in elpa-admin.el indeed allows that.
To recap, here's what it does:

- Git clone <foo> from upstream into .../somewhere/<foo>.
- In that directory, create a <foo>-pkg.el and a <foo>-autoloads.el.
- Byte-compile the .el files.
- Add `.../somewhere` to `package-directory-list`.

The last step is only done once and forall rather than once per package.

IOW it acts as an alternative package installer: package.el could/should
be split into a part that deals with using (activating) the packages
currently installed (i.e. basically `package-activate-all` and the code
it uses) and a part that deals with ELPA repositories and installs
packages into (and remove froms) `package-user-dir`.
[ Side note: the byte-compilation should be moved out of the
  installation step, not only so it can be shared between different UIs
  and installers, but also so we can re-compile upon request.  ]

Then of course you'll want to add further features:

- commands to update packages, i.e. do a `git pull` and recreate/refresh
  the two files.
- support for creating Info docs out of Texinfo.
- support for packages where the Elisp code is not at the root of the
  clone but in some subdirectory.
- allow the user to choose to select an actual *release* rather than the
  bleeding edge.

The above listed features are those that `elpa-admin.el` currently
supports (to some extent, in one form or another), but of course, there
could be more.

Currently, for many packages all you need is the URL of the upstream
repository, but for others we need extra information in the "package
spec", such as where to find the Texinfo source.  In the context of
`elpa-admin.el` the extra info for this "package spec" are provided in
the `elpa-packages` file but I think it would make sense to make it
possible for the package to provide this info directly (e.g. via
additional pseudo-headers in the <foo>.el file).


        Stefan


PS: Note also that `elpa-admin.el` includes a fair bit of code that does
other things, not relevant to this discussion, such as creating tarballs
for ELPA repositories, creating HTML pages, etc...