Re: Easy configuration of a site-lisp directory

[Arthur Miller <arthur.miller@live.com>]

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

> 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>.
If I may interfere, jere is probably good to create a branch (automated) for the
installed version. Update can later checkout to back ot main or release branch,
do a pull, and than do a new installed version.

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

But you only do this for packages in elpa/nelpa? That does not handle random git
repos from www? This does not manage dependencies for gir repos whithout spec.