Re: feature/package-vc has been merged

[Philip Kaludercic]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

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

What might be interesting is providing support for running commands to
build additional software a package needs, e.g. when a package
distributed a C module.  But this wouldn't just be a package-vc thing,
but a thing that would interest all packages.

>> 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/`.

I agree, luckily there hasn't been much need for it up until now.

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

OK, but how would this generalise?  Hard-coding something like "if
'extensions/' is renamed to the '', then add 'extensions/' to
`load-path'" doesn't sound desirable.

>
>         Stefan