Discouraging variants [was: Re: port install efficiency issue]

[Shreevatsa R]

On Wed, Mar 25, 2009 at 12:51 AM, Ryan Schmidt <ryandesign at macports.org> wrote:
>
> On Mar 24, 2009, at 23:05, Shreevatsa R wrote:
>
>> This would be a good starting point to mention my pet peeve with
>> MacPorts, which is the excessive use of variants.
>>
>> Ideally, all ports would enable by default all the features that users
>> might want, and only leave as variants those features which are
>> *definitely* undesirable to significantly many people (and definitely
>> desirable for significantly many). Instead, some ports try to make
>> every feature a separate variant. This is entirely unnecessary: disk
>> space is cheap and shouldn't be considered a cost of enabling the
>> feature by default.
>>
>> It is important to remember that with N variants, there are 2^N
>> potential versions to test -- such combinatorial explosion is hard to
>> maintain and introduces many bugs. There will be situations where
>> variants are absolutely necessary, but if there can be consensus
>> against variants, and if the Guide (etc.) could suggest to maintainers
>> that variants should only be used when necessary, I hope it will lead
>> to some improvement.
>
> I am constantly telling people on the mailing list to use variant sparingly,
> only when absolutely necessary.
>
> Variants frequently don't get tested when ports are updated, so things break
> without the maintainer realizing it.

Exactly! I am glad there is some consensus on this point, although
some people still disagree.

> Are there any specific ports you can point out that have more variants than
> you think they need?

Well my hope was to influence policy, and didn't particularly want to
point fingers -- after all, maintainers providing variants do so in
the belief that they are helping the users by "giving them more
options". :-) Still, just as an indication of the current state of
variants, I compiled a list: after ignoring platform variants and
"universal", there are 130 ports with at least 4 variants: that's
already 16 configurations (ignoring conflicts etc.), which is more
than most maintainers have time to test. See
http://web.mit.edu/vatsa/Public/macports-var/variants-04.txt (or see
http://web.mit.edu/vatsa/Public/macports-var/ for the ~400 ports with
at least two variants, etc. There are a dozen ports with *16* or more
variants. In some cases all of them can be justified, but in many
others it  is hard to imagine someone who would want one subset of the
features and be actively harmed by the rest.)

The broader point is here that a package maintainer is *not* doing the
user a service by providing a lot of options. It is very frustrating
to install something, find out later that there's some feature
missing, and have to install again with a different variant. It is
also frustrating to have to always check variants first before
installing (not only of what one is installing, but also of its
dependencies), or maintain one's own "variants.conf" (or "USE flags"
or whatever arbitrary configuration mechanism). More generally, it is
the packager's *job* to make choices for the user[1]; not doing so is
just evading responsibility. Simply throwing every possible option as
a variant, just because one couldn't decide if someone would *not*
want it or not, simply increases the chances of failure[2], and is not
pleasant to anyone, especially Mac users accustomed to encountering
decisions Done Right. Having to pick from so many choices feels
awful[3,4]. Just design for yourself[5], and if there are disgruntled
users they'll let you know.
There, I'm off my soapbox. Really, just please read [1].

Back to MacPorts specifically, a few humble suggestions: always
install docs unless there is a big dependency like Doxygen (also worth
considering: is doxygen *really* a very big dependency? :)), in which
case make it a separate port. There shouldn't be "no_docs" variants:
no one really *needs* not to install docs. More generally, install all
features wherever possible (e.g. why is mp_completion a variant for
zsh instead of being installed by default? Just a random example from
the bottom of the list, not complaining about that port specifically)
and where there are cases where this is really "too" huge (say, wrt
build time, not disk space), have just one variant, between a sensible
"light" version and the "heavy" version.
Bug #126 still needs to be fixed, but maybe it can be made less important. ;-)

Regards,
Shreevatsa

[1]: http://www.joelonsoftware.com/uibook/chapters/fog0000000059.html
[2]: https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00861.html
[3]: http://www.columbia.edu/~ss957/articles/Choice_is_Demotivating.pdf
[4]: http://www.amazon.com/dp/0060005688
[5]: http://www.37signals.com/svn/posts/904-why-we-disagree-with-don-norman