package.el: soft dependencies?

package.el: soft dependencies?

[Yuri D'Elia]

Several packages support additional features when certain other packages
are also installed, but right now the list of additional packages which
are not strict dependencies are "buried" in the commentary.

I know I do the same: I only put strict dependencies in Package-Requires.

I'd love to be able to add and read about "soft" dependencies when
browsing for packages (just like Debian's Suggests).

This could be accomplished with a Package-Suggests header, with exactly
the same format as Package-Requires. package.el would just need to
present this information in the package description page, for the user
to inspect.

What do other people think?

Re: package.el: soft dependencies?

[Rasmus]

Yuri D'Elia <wavexx@thregr.org> writes:

> This could be accomplished with a Package-Suggests header, with exactly
> the same format as Package-Requires. package.el would just need to
> present this information in the package description page, for the user
> to inspect.

But for optional dependencies you'd want to know what you get when
installing more stuff, also within the package manager.  So there should
also be a one line summary of what the dependency adds (this is how pacman
works; I don't remember how verbose apt is).

Rasmus

-- 
Spil noget med Slayer!

Re: package.el: soft dependencies?

[Yuri D'Elia]

On 14/07/15 23:28, Rasmus wrote:
> Yuri D'Elia <wavexx@thregr.org> writes:
> 
>> This could be accomplished with a Package-Suggests header, with exactly
>> the same format as Package-Requires. package.el would just need to
>> present this information in the package description page, for the user
>> to inspect.
> 
> But for optional dependencies you'd want to know what you get when
> installing more stuff, also within the package manager.  So there should
> also be a one line summary of what the dependency adds (this is how pacman
> works; I don't remember how verbose apt is).

apt has no detail as of why a package is suggested, and it works well
enough for me. Presenting the list briefly, as done for the requirements
would do.

Normally, when a package is suggested, I explicitly look for it in the
docs/description. Just knowing it's suggested does the job.

Most of the time the package name makes it immediately obvious though,
so it's rather straighforward.

Re: package.el: soft dependencies?

[Yuri D'Elia]

On 14/07/15 23:52, Yuri D'Elia wrote:
>> But for optional dependencies you'd want to know what you get when
>> installing more stuff, also within the package manager.  So there should
>> also be a one line summary of what the dependency adds (this is how pacman
>> works; I don't remember how verbose apt is).
> 
> apt has no detail as of why a package is suggested, and it works well
> enough for me. Presenting the list briefly, as done for the requirements
> would do.

To be clear: not that I won't like a summary line, but I don't think
it's required at all to still be a great addition in usability.

Re: package.el: soft dependencies?

[Artur Malabarba]

[-- Attachment #1: Type: text/plain, Size: 257 bytes --]

This feature would be a good addition, and would be pretty easy and (more
importantly) backwards compatible. I've seen this asked by a few people
already.
I also think it needs the summary. I use both pacman and apt, and the
summary makes a big difference.

[-- Attachment #2: Type: text/html, Size: 284 bytes --]

Re: package.el: soft dependencies?

[Bozhidar Batsov]

[-- Attachment #1: Type: text/plain, Size: 385 bytes --]

+1 - this would be a great addition.

On 15 July 2015 at 13:06, Artur Malabarba <bruce.connor.am@gmail.com> wrote:

> This feature would be a good addition, and would be pretty easy and (more
> importantly) backwards compatible. I've seen this asked by a few people
> already.
> I also think it needs the summary. I use both pacman and apt, and the
> summary makes a big difference.
>

[-- Attachment #2: Type: text/html, Size: 704 bytes --]

Re: package.el: soft dependencies?

[Stefan Monnier]

> This could be accomplished with a Package-Suggests header, with exactly
> the same format as Package-Requires. package.el would just need to
> present this information in the package description page, for the user
> to inspect.

Sounds good to me.


        Stefan

Re: package.el: soft dependencies?

[Artur Malabarba]

If package.el is going to do this, it might be good to add support for
optional dependencies in other places too, like in the byte-compiler.

For instance, we could have a form like the following

(require-optionally 'projectile
  (projectile-ag projectile-dired ...))

When the byte-compiler reads this, it will try to require projectile.
If projectile is available, great, if it isn't then the compiler
treats all those listed functions and macros as `ignore'.

This would sometimes make it more convenient for the developer to
support optional features, because you would only need to account for
the possibility of them return nil, instead of always being forced to
check if they're `fbound'. Though sometimes you'd still need to check
to manually.

Re: package.el: soft dependencies?

[Tassilo Horn]

Artur Malabarba <bruce.connor.am@gmail.com> writes:

> If package.el is going to do this, it might be good to add support for
> optional dependencies in other places too, like in the byte-compiler.
>
> For instance, we could have a form like the following
>
> (require-optionally 'projectile
>   (projectile-ag projectile-dired ...))
>
> When the byte-compiler reads this, it will try to require projectile.
> If projectile is available, great, if it isn't then the compiler
> treats all those listed functions and macros as `ignore'.
>
> This would sometimes make it more convenient for the developer to
> support optional features, because you would only need to account for
> the possibility of them return nil, instead of always being forced to
> check if they're `fbound'. Though sometimes you'd still need to check
> to manually.

IMHO, something like

  (if (fboundp 'projectile-something)
      (projectile-something arg)
    (some-fallback arg))

is much more obvious to be identified as a call to something optional
rather than

  (or (projectile-something arg) (some-fallback arg))

Well, and in the case where nil is a valid return value you couldn't
differentiate at all, e.g., with

  (projectile-project-buffer-p (current-buffer) root)

you the current buffer could either be no project buffer under root or
projectile could simply not be available.

Bye,
Tassilo