Variants handling: my $0.02.

N_Ox nox at macports.org
Mon Feb 4 11:23:45 PST 2008


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!
>
> Rainer

--
Anthony Ramine, the "Ports tree cleaning Maestro".
<nox at macports.org>



More information about the macports-dev mailing list