[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: package-vc support for :files keyword

From: Philip Kaludercic
Subject: Re: package-vc support for :files keyword
Date: Fri, 22 Sep 2023 13:26:53 +0000
User-agent: Gnus/5.13 (Gnus v5.13)

Stefan Kangas <stefankangas@gmail.com> writes:

> Jonas Bernoulli <jonas@bernoul.li> writes:
>> Tony Zorman <tonyzorman@mailbox.org> writes:
>>> This is not just for multiple packages in a single repository—at least
>>> one has to somewhat broaden what "multiple packages" means. Some
>>> packages include small shims for bigger projects, and inadvertently
>>> require them as dependencies. The original issue[1] on the
>>> vc-use-package repo mentions org-ql[2], more specifically its helm
>>> integration in the form of helm-org-ql.el. Some people might not want to
>>> pull down helm as a dependency just for one file that they are not going
>>> to use anyways.
>>> I'm not sure how common of a situation this actually is, but at least
>>> for the big completion frameworks—helm and ivy—it's not totally unheard
>>> of.
> If a user uses foo, and also bar, then foo may support bar optionally,
> or the other way around.  We have ways of dealing with that without an
> explicit dependency, including e.g. autoloads and `eval-after-load'.
> The user will simply install both foo and bar, and things should ideally
> work as expected, including their integration.  See for example
> use-package-ensure-system-package.el.
> Is there any reason why that can't work?
> A separate but related issue is that we should really teach package.el
> to deal with optional dependencies.  I personally like Debian's model
> with "Recommends" and "Suggests" sections.

What is the difference between the two?

>> Here's a complete list for all of these packages that are available on
>> Melpa.  Obviously not all of these pairings fall into the "foo and
>> helm-foo share a repository" category, but you can get an idea of what
>> other reasons exist for splitting a repository into multiple packages,
>> based on the names of the packages/libraries.  I have included links to
>> the repositories, so you can quickly jump there, when only looking at
>> the names is not enough.
        > Having reviewed this list, my conclusion remains that there is usually
> no need for splitting up packages like this.

I might be mistaken, but I believe that MELPA and specifically
package-lint advise against using {with,}eval-after-load, encouraging
splitting up packages like these.

reply via email to

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