Re: Easy configuration of a site-lisp directory

[Arthur Miller]

Arthur Miller <arthur.miller@live.com> writes:

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

Would you and everybody else interested in this topic like to try a
small patch to test the idea with symlinks? It literally takes 3 lines
of code to make this happen in package-install-file function.

I did add a customize var to enable/disable the behaviour, so it is more
than 3 lines, but in principle, we can just create a symlink instead of
copying files. I have tested and it worked fine with help functions,
Emacs loaded everything nicely and lookup seems to work. Autoloads were
correctly generated and package-quickstart-refresh worked out of the box.

The only inconvenience is that one has to define version header in one (main)
file, for example only thing I needed to make my own helm-git-branch

https://github.com/amno1/helm-git-branch

install as package was to add the comment:

;; Version: 0.1

I attached both patch and patched package.el for the convenience. I would
really appreciate opinions. Would this be acceptable on Windows and MacOS
too? I have only tested on my Arch Linux. Any potential problems?

local-repos-as-symlink.patch
Description: Text Data

package.el
Description: Text document