Re: feature/package-vc has been merged

[Stefan Monnier <monnier@iro.umontreal.ca>]

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