>> Without such a system the package could be without use in many cases.
> Many is probably the word of contention here. If you take a look at
> elpa.git:elpa-packages, you'll find only a few :make or :shell-command
> directives, none of which are critical. nongnu.git:elpa-packages has
> non at all.
Indeed. We don't use `make` or `ninja` to compile the ELisp files,
instead we impose a standardized way to compile them.
[ And those packages which rely on special build procedures will often
suffer from problems with the native compiler, which will lazily
recompile the files to native code without paying attention to the
special build requirements. ]
> One thing I worry about, but which has also been discussed
> here are :renames.
Indeed. Currently `elpa-admin.el` doesn't obey them when using "install
from Git" (it does obey them when building the tarballs, of course) :-(
> E.g. Vertico uses these to move extensions from a subdirectory to the
> main directory for packaging. But moving the files would be
> registered by the VCS, and could make committing changes more
> difficult. Maybe we could create symbolic/hard links instead
> of renaming?
Moving is definitely out of the question, but symlinks and hardlinks are
also problematic. We should probably document that `:renames` are not
fully supported in all cases and should thus be avoided.
I currently count 6 :renames, two for `extensions/` and 4 for `docs/`.
AFAIK Those for docs are needed only because `package-install` handles
`.info` files only in the root directory of packages, but that doesn't
afflict `package-vc`, so we should be able to find a better solution.
Those for `extensions/` can be handled by adding `extensions/` to
the `load-path` in the `<pkg>-autoloads.el` generated by
`package-vc-install`.
Stefan
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