Re: package-vc support for :files keyword

[Philip Kaludercic]

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.