[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.
Stefan
- Re: feature/package-vc has been merged, (continued)
- Re: feature/package-vc has been merged, Eli Zaretskii, 2022/11/07
- Re: feature/package-vc has been merged, Philip Kaludercic, 2022/11/08
- Re: feature/package-vc has been merged, Stefan Monnier, 2022/11/08
- Re: feature/package-vc has been merged, Philip Kaludercic, 2022/11/09
- Re: feature/package-vc has been merged, Eli Zaretskii, 2022/11/09
- 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, Philip Kaludercic, 2022/11/09
- Re: feature/package-vc has been merged, Stefan Monnier, 2022/11/09
- Re: feature/package-vc has been merged, Philip Kaludercic, 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, Philip Kaludercic, 2022/11/09
- Re: feature/package-vc has been merged, Stefan Monnier, 2022/11/16
- Re: feature/package-vc has been merged, Philip Kaludercic, 2022/11/16
- Re: feature/package-vc has been merged, Stefan Monnier, 2022/11/16
- Re: feature/package-vc has been merged, Philip Kaludercic, 2022/11/16
- Re: feature/package-vc has been merged, Stefan Monnier, 2022/11/16
- Re: feature/package-vc has been merged, Philip Kaludercic, 2022/11/16
- Re: feature/package-vc has been merged, Stefan Monnier, 2022/11/16