Hello there, One thing that is great about MacPorts is to be able to customise ports with variants. But there is two problems with them, I've thought about 2 new syntaxes to handle these problems. First, when a variant actually does something only when it is DISABLED, you would usually need to write: variant some_variant {} post-patch { if {![variant_isset some_variant]} { # Do something } } Why wouldn't we just write: variant -some_variant { post-patch { # Do something } } Now, what if we want to do something when the variant is enabled, and something else when it is disabled? Why won't we write that: variant some_variant { # Do something } else { # something else } Isn't that neat? 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". Then, on upgrade, we would just have to compare the name of the variant in the portfile (-some_variant) with each item of the list of selected variants to check whether or not we should enable it. No need to use default_variants. 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 } But maybe all of this is just a "No more alive nerve cells in my brain." Regards, -- Anthony Ramine, the "Ports tree cleaning Maestro". <nox@macports.org>
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@1.0+another_variant-some_variant 2) some_port@1.0+another_variant 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...
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... Also, what is the difference between these and which one is a default variant? variant foo { # do something } variant -bar { # do something } else { # do something } variant -baz { # do something } 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 } I like the overall idea to simplify the default variants handling! Rainer
On Feb 4, 2008, at 11:13, Rainer Müller wrote:
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.
Having to specify "-ssl +gnutls" is stupid. The way I see it, "ssl" and "gnutls" are two radio buttons. To select the radio button you want, you shouldn't also have to manually deselect the radio button you don't want. It should be automatic. Fixed the lynx port so it behaves this way, in r33752. (No new portfile syntax needed. :))
Ryan Schmidt wrote:
Having to specify "-ssl +gnutls" is stupid. The way I see it, "ssl" and "gnutls" are two radio buttons. To select the radio button you want, you shouldn't also have to manually deselect the radio button you don't want. It should be automatic. Fixed the lynx port so it behaves this way, in r33752. (No new portfile syntax needed. :))
Well, I just wanted to say how it is done until now. Indeed, your fix is a good thing as it also fixes the issues with upgrading. Anyways, I was just talking about how we would write this "radio button choice" in a new syntax where default_variants will be gone. Rainer
On Feb 4, 2008, at 11:46, Rainer Müller wrote:
Ryan Schmidt wrote:
Having to specify "-ssl +gnutls" is stupid. The way I see it, "ssl" and "gnutls" are two radio buttons. To select the radio button you want, you shouldn't also have to manually deselect the radio button you don't want. It should be automatic. Fixed the lynx port so it behaves this way, in r33752. (No new portfile syntax needed. :))
Well, I just wanted to say how it is done until now. Indeed, your fix is a good thing as it also fixes the issues with upgrading.
Anyways, I was just talking about how we would write this "radio button choice" in a new syntax where default_variants will be gone.
default_variants functionality should not be removed. It is necessary. When there are two or more conflicting options, one of which must be selected, it is more intuitive for the user if these are both expressed as variants, one of which is enabled by default. See lynx, minivmac, pdftk, etc.
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@1.0+another_variant-some_variant 2) some_port@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@macports.org>
Le 4 févr. 08 à 18:32, Ryan Schmidt a écrit :
On Feb 4, 2008, at 11:13, Rainer Müller wrote:
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.
Having to specify "-ssl +gnutls" is stupid. The way I see it, "ssl" and "gnutls" are two radio buttons. To select the radio button you want, you shouldn't also have to manually deselect the radio button you don't want. It should be automatic. Fixed the lynx port so it behaves this way, in r33752. (No new portfile syntax needed. :))
I had another idea for this one sometimes ago: variant_group cypher { choice ssl { ... } choice gnutls { ... } } We could have attributes for the group like "unique" and "required" to say we need one and only one choice in the group. Regards, -- Anthony Ramine, the "Ports tree cleaning Maestro". <nox@macports.org>
On Feb 4, 2008, at 11:23 AM, N_Ox wrote:
[ ... description of new variant syntax ...]
First, let me just say how happy I am to see people revisiting the topic of variants and how to better express them. I think variants are one of the more powerful features of MacPorts (that no other port systems, to my knowledge, share), but also the most likely to cause confusion and mayhem if misapplied across the collection (I think Landon went through periods of both pride and remorse over variants for just this reason). Second, given that the "platform" procedure also feeds directly into variants, I hope that cleaning up variants will include cleaning up the platform syntax and general mechanism. More specifically, as I pointed out a couple of weeks ago, we're starting to see a lot of duplicated code across platform clauses because it's not possible to have wildcards in platform clauses or even just be able to do platform includes, e.g.: platform darwin 8 i386 { platform darwin 7; # include the generic platform code for darwin 7 ... code specific to darwin 8/i386 here ... } Given how frequently the platform clauses are being used, and the fact that they're only going to get more prolific as further releases of MacOSX come out, I'd say cleaning them up is at least as important as cleaning up variants (which, again, they just use at the back-end anyway). - Jordan
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@1.0+another_variant-some_variant 2) some_port@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@macports.org>
_______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
2008/2/4, N_Ox <nox@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@1.0+another_variant-some_variant 2) some_port@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
participants (5)
-
Jordan K. Hubbard
-
N_Ox
-
Rainer Müller
-
Ryan Schmidt
-
Thomas de Grivel