[Exherbo-dev] Alternatives descriptions

Benedikt Morbach moben at exherbo.org
Sun Sep 17 19:31:14 UTC 2017


Hi,

On Thu, Sep 14, 2017 at 6:09 PM, Bo Ørsted Andresen <zlin at exherbo.org> wrote:
> Hello,
>
> Couple years ago support for descriptions for alternatives was introduced. E.g.:
>
> ALTERNATIVES_cc_DESCRIPTION="System-wide C compiler"
> ALTERNATIVES_vi_DESCRIPTION="Default provider for the vi text editor"
>
> in the bottom of alternatives.exlib. More alternatives need to start using this
> but it's a start. If you run `eclectic` these descriptions are shown. If you
> run `eclectic vi help` the vi alternative description is also shown.
>
> If you run `eclectic vi` it is, however, not shown. That's dumb. Attached in
> 0001-Show-description-by-default-in-eclectic-alternative-.patch for ::arbor is
> a solution to that. The normal default action is usage. Help prints the
> description and then usage. So seems okay.

Agreed.
Additionally I would change the formatting a bit because I for one would
never have seen that description in this:

Default provider for the vi text editor
Usage: eclectic vi <action> <options>

At least a newline before the "Usage:..." bit, maybe some color or
underline as well?

But we can bikeshed that separately afterwards.

> Additionally the desire to provide descriptions for alternative providers has
> been discussed. Attached in
> 0001-Show-contents-of-_description-file-if-it-exists-in-e.patch for ::eclectic
> and 0002-Add-alternatives_for_with_description-which-allows-s.patch for ::arbor
> is a way to show provider descriptions in `eclectic ${alternative} list`
> output.

That seems sensible. Though I'd make the first loop start at 0 as well and do
$((n+1)) for the list index instead of n-1 everywhere else, if only to
be consistent
with the second loop

> To specify provider description has been added a new
> `alternatives_for_with_descriptions` function which takes a fourth description
> argument and puts it in
> /etc/env.d/alternatives/${alternative}/${provider}/_description similar to how
> importance is stored.
>
> Does anybody have suggestions for a better name for
> `alternatives_for_with_description`? Comments?

I'd just add another argument to alternatives_for. It can/should be empty for
many things, like python3 versions, but it would be more consistent and more
people would know that it exists, compared to a rarely used
_with_description version.



More information about the Exherbo-dev mailing list