show default_variants in "port variants foobar"

[themolok@…]

I tried to write a patch for it, but I failed (I never wrote a single line of tcl, and I'm a pretty lame programmer), anyway, I think it's really trivial for who knows the port (the tcl script) codebase.

Now, for example, "port variants git-core" returns (note that doc is in default_variants):

git-core has the variants:
        universal
        doc: Install HTML and plaintext documentation
        svn: Bi-directional subversion repository support

I'd like to have something like:

git-core has the variants:
        universal
        doc: Install HTML and plaintext documentation (default)
        svn: Bi-directional subversion repository support

[ryandesign@…]

This request just came up on the mailing list too.

I've been manually adding "(default)" after all of my variant descriptions, but clearly it would be better if base did this automatically.

[jan.matousek@…]

Cc Me!

[michele.cella@…]

+1

I was looking for the same thing today.

UI wise I think showing a plus sign besides default variants it's the best thing as you don't need to scan to the end of the variant description to search for "(default)" and it's coherent with the mechanism you use to invoke non default variants or negating them.

That's what I would expect:

git-core has the variants:
     universal
    +doc: Install HTML and plaintext documentation
     svn: Bi-directional subversion repository support

[perry@…]

I addressed this in Ticket #15628 (r43475).

[raimue@…]

I began to use some special syntax in port info to indicate the reason for this variant to be selected. Currently port adds prefixes to variants for three different cases:

• + explicitely selected on the command-line
• [+] selected by default_variants
• (+) selected by variants.conf

I haven't heard any feedback so far on this, especially if you got better ideas how to indicate this. But at last it would be good to use the same syntax in port variants.

[perry@…]

Sounds good; for the sake of consistency they should be the same. I'll go ahead and change the syntax to [+] in trunk.

[perry@…]

Syntax was changed in r44058.

[perry@…]

Cleaned up the code in r45034.