Eli Zaretskii <eliz@gnu.org> writes: >> > Which steps are those, and why do we have to do it manually? >> >> Let us assume `default-directory' is (locate-user-emacs-file "elpa"). >> If I run "M-! git clone https://some.git.host.com/path/to/repo/foo.git";, >> then I'll just have a directory called "foo", right? If I want to byte >> compile the files I'd e.g. have to open foo in Dired, mark all Emacs >> Lisp files, byte compile them, then run something like >> `make-directory-autoloads' myself. Then I'd have to find the main file, >> check the dependency list and run M-x package-install on every one that >> is missing, again one-by-one. >> >> You don't have to do this for `package-install', because it invokes >> `package-unpack' that takes care of those details. As >> package-vc-install doesn't use prepared tarballs, the equivalent process >> is a bit different (thus we have `package-vc-unpack'), but the intention >> is the same. Bundle all the repetitive task into a single command. > > OK, but my question was why all of this gets magically done when you > clone the repository outside ~/.emacs.d/elpa, but does not get done > when you clone it inside? I thought this is what you were alluding to > when I asked why not clone into ~/.emacs.d. Oh no, I'm sorry if I implied this somehow. This is neither the case in or outside of ~/.emacs.d/elpa. Somehow, someone has to do all of this. And one someone is package-vc. >> > (if (fboundp 'normal-top-level-add-subdirs-to-load-path) >> > (normal-top-level-add-subdirs-to-load-path)) >> > >> > Example of directories which need this is the site-lisp directory. >> >> I was not familiar with this function. >> >> > Why cannot we do something like this in this case? >> >> I would have to try this out, but my worry is that in some cases this >> could add too many non-lisp directories. > > The function can be easily extended to only add directories in which > we have *.el files. This might work well enough most of the time, but I don't think we always want this. >> It still seems more elegant to encode what the lisp directory is in the >> package description. > > You consider manual configuration of a package to be more elegant than > automatically finding the directories to put on load-path? Eh, I am not sure what we are talking about anymore :/ I think it is best for me to reiterate. Both elpa.git and nongnu.git have package specifications in "elpa-packages", that among other things may contain properties indicating what directory the lisp files are located in. elpa-admin.el uses this information to prepare the tarballs for distribution. These package specifications are now also published in a way that package-vc can process them. For GNU ELPA you can find these here: https://elpa.gnu.org/packages/elpa-packages.eld. After cloning a package repository, package-vc can use the `:lisp-dir' property from a package specification to figure out what directory is to be added to the load-path, where the files are that should be byte-compiled, auto-loaded, etc. I am proposing we make use of this available information instead of guessing or making broad assumptions like that all lisp code is of interest.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4