[Top][All Lists]

[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 14:53:00 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)

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.

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]