emacs-devel
[Top][All Lists]
Advanced

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

Re: package-vc support for :files keyword


From: Stefan Kangas
Subject: Re: package-vc support for :files keyword
Date: Fri, 22 Sep 2023 05:38:25 -0700

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.

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



reply via email to

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