variants set with default_variant don't propagate the same way as variants set by the user do.

[RJVB (René Bertin)]

I'm not sure if this is a bug or a feature, or something I'm doing wrong (so fee free to change the ticket type).

Consider an audio-related port:foo depending (directly or indirectly) on port:portaudio in a future in which that port has moved Jack support to a +jack variant (as I should have proposed by now). Foo does

variant jack description "Enable the use of Jack" {
    # whatever else we need to do for Jack support
}
# we enable Jack support by default, but don't need to make it a
# hard requirement on all dependencies
default_variants +jack

I for one would expect that the port will behave the same way when installing from scratch if one does

> port install foo

or

> port install foo +jack

because that's how I interpret the intended effect of the default_variants statement.

When you test as construct like this with port rdeps it would appear that variants set by default_variants don't propagate the same way, at least not for indirect dependencies on port:portaudio. IOW, if portaudio is an indirect dependency of port:foo, I'm seeing (as expected)

> port rdeps foo +jack
...
 portaudio
  jack
...

All other things being equal I'd expect to see the same output when I do port rdeps foo, but in reality the output from that command is the same as the output of port rdeps foo -jack.

If this is intended, is there a way to set a variant programmatically so that it propagates? I already tried various approaches (including variant_set jack but if that function does anything it's done in the wrong scope).

[RJVB (René Bertin)]

(ouch, and if someone can remove the last 2 characters from the subject I'd be grateful :-/)

[ryandesign (Ryan Carsten Schmidt)]

It behaves as intended, as far as I know, and no, there's no support for what you want to have happen.

[RJVB (René Bertin)]

I'd be curious to know why this is the intended behaviour, which feels like an inconsistency and probably requires additional processing.