Arthur Miller writes: > Philip Kaludercic writes: > >> Arthur Miller writes: >> >>> Arthur Miller writes: >>> >>>> Arthur Miller writes: >>>> >>>>> Philip Kaludercic 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?