While working on the options system port to Rust, ...
# development
h
While working on the options system port to Rust, I noticed something I didn't expect: Apparently removing an item from a list-valued option (via the
-["foo"]
syntax) is intended to override any attempt to re-add the item at a higher precedence (e.g., if removed in an env var, you cannot add it back via a CLI flag, you have to overwrite the entire list value via CLI flag to reintroduce the removed value). These tests show that this is deliberate, as does the implementation. Can anyone remember/hypothesize why this is so?
I will modify the rust code to comply with this, for backwards compatibility. But it's noteworthy that the docs get this wrong: https://www.pantsbuild.org/2.19/docs/using-pants/key-concepts/options#list-values
"A value can be preceded by -, which will remove the elements from the value obtained from lower-precedence sources."
Is inaccurate, it will remove the elements from any sources, even higher-precedence ones.
So it's more accurate to think of removals as a filter applied after all additions
b
I'm guessing you've dug up the source of this behaviour https://github.com/pantsbuild/pants/commit/a5c25d2b17740d449de3bb24780ad1b5d4e63f7f ? Notably, the docs are correct there. I guess it makes somewhat sense if I think of
-
as a "I really don't want this to appear, no matter what"?
h
Not quite, that PR says "Filters apply to the entire list constructed so far" but the "so far" part is inaccurate
There must have been a solid reason for this, since it's harder to implement, but I'm not sure what
b
Ah, I was reading the "Filters take precedence over appends" qualifier. for that PR
h
I really wish I had documented the reason back when I implemented all this
p
Sounds like we need another symbol for "drop this, but respect precedence". Maybe
^["foo"]
? (where
^
is the regex character negation
[^...]
)? or maybe:
+[^"foo"]
or
+[-"foo"]
so that the
+
respects precedence?
Hmm. If the list has ints instead of strings, using
-
inside the brackets becomes ambiguous (drop the 4, or add a negative 4):
+[-4]
, so it would probably need to be the carat:
+[^4]
...
So, maybe a
!
?
+[!4]
or
+[!"foo"]
h
Eh, no one has asked for this, so I'm not inclined to offer it
1
There is always the escape hatch of overwriting the entire value instead of appending back