Variants handling: my $0.02.

[Thomas de Grivel]

2008/2/4, N_Ox <nox at macports.org>:
>
> Le 4 févr. 08 à 18:13, Rainer Müller a écrit :
>
> > N_Ox wrote:
> >> These two sugar syntaxes would make the variant writing process
> >> cleaner.
> >> But maybe they could help us more...
> >> Let's say the variants which do something only when they are
> >> disabled (variant -some_variant) are always enabled by default.
> >> In this setup, `sudo port install some_port +another_variant`
> >> would install some_port @some_version+another_variant+some_variant.
> >> In the registry, we would save "some_variant another_variant" as
> >> the list of selected variants.
> >> Now, let's explicitely disable the variant: sudo port install
> >> some_port -some_variant +another_variant.
> >> In the registry, we would save "-some_variant another_variant".
> >
> > Should the selection of -some_variant be user visible or just
> > stored internal?
> > port installed some_port
> >  1) some_port at 1.0+another_variant-some_variant
> >  2) some_port at 1.0+another_variant
>
> Shown to the user
>
> > The main problem about default_variants in it's current
> > implementation is that we don't store disabled variants and re-
> > select them on upgrade...
>
> AFAIK, default_variants is just a procedure that append any argument
> to the list of enabled variants in the registry.
> This syntax remove the need to use default_variants.
>
> >> No need to use default_variants.
> >
> > So how would I tell that a +variant is default? E.g. the lynx port
> > provides support for OpenSSL (+ssl) and GNU TLS (+gnutls). They are
> > conflicting variants, with +ssl in default_variants. But the user
> > has the choice to install it with GNU TLS by using -ssl +gnutls.
> >
> > But how would I write that in the new syntax?
> >
> >> No more "Why the hell this variant is enabled when I upgrade this
> >> port?" whining.
> >> No more "no_x11" variant:
> >> variant -x11 {
> >>     # no x11
> >> } else {
> >>     # x11
> >> }
> >
> > And which of those will be the default...? You said -some_variant
> > will be enabled by default, or did I understand that wrong? In
> > which cases will -some_variant be enabled by defaul? If it got no
> > else-block?
> > I think that will end up more complex than it currently is...
>
> Not complex, at least that's not what I think.
> The algorithm would be:
>
> foreach {name} ${variants} {
>         # Foreach variant defined in the portfile
>
>         if {[lindex ${selected_variants} ${name}] > -1} {
>                 # If this variant is selected.
>                 eval_variant ${name} # The first block.
>         } elseif {[variant_has_else_block ${name}]} {
>                 eval_else_variant ${name} # The else block
>         }
> }
>
> If a -variant hasn't been SELECTED (through the command line), it is
> ENABLED, it did NOT show up in `port installed` and the else block
> will be evaluated.
> If a (+)variant hasn't been SELECTED (through the command line), it
> is DISABLED, it did NOT show up in `port installed` and the else
> block will be evaluated.
>
> So the behaviour is in fact the very same for both of them.
>
>
> > Also, what is the difference between these and which one is a
> > default variant?
> >
> > variant foo {
> >    # do something
> > }
>
> A normal variant:
> port install            -> @...         (nothing evaluated)
> port install +foo       -> @...+foo     (first block evaluated)
> port install -foo       -> @...         (nothing evaluated)
>
> > variant -bar {
> >    # do something
> > } else {
> >    # do something
> > }
>
> A negative variant which does something else when it's not enabled:
> port install            -> @...         (else block evaluated)
> port install +bar       -> @...         (else block evaluated)
> port install -bar       -> @...-bar     (first block evaluated)
>
> > variant -baz {
> >    # do something
> > }
>
> A negative variant:
> port install            -> @...         (nothing evaluated)
> port install +baz       -> @...         (nothing evaluated)
> port install -baz       -> @...-baz     (first block evaluated)
>
> > What if we add some new flag? I like the idea of variant -
> > some_variant, but maybe we could also add a default keyword which
> > says if this variant is going to be installed by default.
> >
> > Like this:
> > variant x11 description {Install X11 support} default {
> >    # x11
> > } else {
> >    # no x11
> > }
>
> Sure. The -variant syntax just sounds more intuitive to me, but one
> could say I'm strange.
>
> > I like the overall idea to simplify the default variants handling!

I like it. If there is some kind of poll here, I'm in   =)

-- 
  Thomas de Grivel