[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: feature/package-vc has been merged
From: |
Stefan Monnier |
Subject: |
Re: feature/package-vc has been merged |
Date: |
Wed, 09 Nov 2022 12:25:26 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) |
>> 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
- Re: feature/package-vc has been merged, (continued)
- Re: feature/package-vc has been merged, Björn Bidar, 2022/11/10
- Re: feature/package-vc has been merged, Stefan Monnier, 2022/11/09
- Re: feature/package-vc has been merged, Björn Bidar, 2022/11/10
- Re: feature/package-vc has been merged, Stefan Monnier, 2022/11/09
- Re: feature/package-vc has been merged, Eli Zaretskii, 2022/11/10
- Re: feature/package-vc has been merged, Philip Kaludercic, 2022/11/09
- Re: feature/package-vc has been merged, Björn Bidar, 2022/11/09
- Re: feature/package-vc has been merged, Philip Kaludercic, 2022/11/09
- Re: feature/package-vc has been merged, Björn Bidar, 2022/11/10
- Re: feature/package-vc has been merged, Stefan Monnier, 2022/11/09
- Re: feature/package-vc has been merged,
Stefan Monnier <=
- Re: feature/package-vc has been merged, Philip Kaludercic, 2022/11/09
- Re: feature/package-vc has been merged, Stefan Monnier, 2022/11/09
Re: feature/package-vc has been merged, Rudolf Adamkovič, 2022/11/05
- Re: feature/package-vc has been merged, Rudolf Adamkovič, 2022/11/05
- Re: feature/package-vc has been merged, Philip Kaludercic, 2022/11/06
- Re: feature/package-vc has been merged, Rudolf Adamkovič, 2022/11/06
- Re: feature/package-vc has been merged, Philip Kaludercic, 2022/11/07
- Re: feature/package-vc has been merged, Rudolf Adamkovič, 2022/11/07
- Re: feature/package-vc has been merged, Philip Kaludercic, 2022/11/08
- Re: feature/package-vc has been merged, Rudolf Adamkovič, 2022/11/08