Re: feature/package-vc has been merged

[Philip Kaludercic <philipk@posteo.net>]

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

> Philip Kaludercic [2022-11-09 19:04:56] wrote:
>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>>> I have made :lisp-dir a general property of a package description.  This
>>>> might be set in package-vc when generating the <PKG>-pkg.el, but in
>>>> principle any (non-vc) package could make use of this to indicate a
>>>> subdirectory where lisp files are stored.  For now this is something
>>>> that will probably only interest package-vc.
>>>
>>> Hmm... but if a package does that in an ELPA archive (i.e. the
>>> `:lisp-dir` thingy appears in the `archive-contents`), then this package
>>> will not be installed correctly when installed with an older
>>> Emacs, right?
>>>
>>> IOW, it's an extension of the ELPA protocol.
>>
>> Strictly speaking yes, but without any specification it is hard to say.
>> All this is intended as is an extra field that is stored in a package
>> description file.
>>
>> Do you have any other suggestion that could be implemented to solve the
>> immediate problem that package-vc has (lisp files are located in some
>> sub-directory and we want to avoid loading package-vc during
>> initialisation).
>
> I don't understand the problem you're trying to solve: package-vc
> already has access to this `:lisp-dir` info and it can generate the
> autoloads file on its own, so I can't see why `package.el` would need to
> know about it.

You are right, it is not necessary but...

>>> I do think it's getting time to update the protocol based on the
>>> experience gained over the last 10 years, but I'm really not convinced
>>> `:lisp-dir` is a good addition.
>>>
>>> E.g. a thing I'd find more interesting would be to let the tarball provide
>>> its own <PKG>-autoloads.el (which is in charge of adding whichever
>>> lisp-dirs it wants).
>>
>> That sounds like a better idea.
>
> But for `package-vc` that's already the case since it has complete control
> over how the `<foo>-pkg.el` and the `<foo>-autoloads.el` are generated.

..., this is handled by `package-vc--unpack-1' which up until now did
not depend on a package specification, just a package description.  This
is so, so that it can be invoked by `package-vc-refresh' or
`package-vc-install-from-checkout' which all don't necessarily have
specifications.  It would be imaginable to store the specification in a
file like <PKG>-spec.eld, but there are too many files already so this
is just getting more and more messy.

If you believe that this is not worth it or shortsighted on my part,
I'll implement the code necessary for what you suggest to work.