Re: Easy configuration of a site-lisp directory

[Arthur Miller]

Philip Kaludercic <philipk@posteo.net> writes:

> Arthur Miller <arthur.miller@live.com> writes:
>
>> Arthur Miller <arthur.miller@live.com> writes:
>>
>>> Arthur Miller <arthur.miller@live.com> writes:
>>>
>>>> Philip Kaludercic <philipk@posteo.net> writes:
>>>>
>>>>> Just wanted to ping this message to check if there is any interest in
>>>>> doing something with my initial suggestion?
>>>>
>>>> I do something similar as you do, but I use it only for some loose
>>>> files I write myself, and for some I download from emacs wiki etc.
>>>>
>>>>>> The fundamental idea is to have an easy-to-use ~/.emacs.d/site-lisp/
>>>>>> directory where a user can clone any repository or create their own,
>>>>>> without having to manually add these to load-path, generate autoloads or
>>>>>> byte compile.
>>>>
>>>> I have a question: is it desirable to use a working git directory as
>>>> installed package? When I write my own files, I usually don't wish to
>>>> copy them over to my "lisp" directory which I autoload in Emacs, untill
>>>> I am done. Admittedly I started doing so before git has entered the
>>>> scene. Now I guess one can switch branches every time one works on a 
>>>> package
>>>> between some development branch and some stable, but isn't it a bit 
>>>> tedious?
>
> I do think this is useful, because it prevents confusion with xref. When
> I am working on my own packages/packages I am contributing to, I want
> M-. to jump to the actual definition I can work on, not a copy that
> might get lost.
Yes, I am aware of that one. I think that is also the reason why people
prefer straight.el. Isn't it possible to advise something in xref to use
the working copy? How do you deal with incomplete code? When you are
working on something and it is not ready to be used in Emacs yet. Do you
switch branches or do you use some other strategy? 

>>> I just looked at package.el and realized that it is already possible to
>>> install directories, I wasn't aware of that fact. So the only extra work
>>> is to make it recognize local paths in a list package-archives list, in
>>> principle.
>
> I assume you mean package-install-file?

I goofed there, I wasn't aware package-archives can already be spciefied
as local paths, forgoett about that one. Sorry I was making noise there.

>>  And  I also realized that package-archives can already deal with local
>>  directories. So everything is there.
>>
>> Users can already install from local repos.
>
> The issue is that this is just a repository

I know, I am aware. It also duplicates the code; working and
installed. But it does offer better granularity what gets installed.

>                         the very least adds a redundant step (fetch the
> code, install the code) and always makes it harder to work on local
True. But we can automate that one. We still have to do fetch if the
source is not on local disk, and some kind of action is still needed, at
least to create autoloads, and maybe to update package-quickstart.el.

The only part we skip is making an extra copy to package-user-dir, all
the other parts are performed anyway. Also package-quickstart expects
everything in package-user-dir so it would have to be hacked.

What I thinking of is benefit of extra complexity a new procedure adds,
like to explain it in user manual etc, compared to if user installs
packages via already existing mechanism, add site-lisp to
package-archives. I have never seen anyone mention that local repos can
be used that way on any blog or anywwhere, I wasn't myself aware of that
one.