Closed jayvdb closed 1 year ago
That sounds reasonable to me.
Another reason I've run into is TRAVIS_JDK_VERSION
, which is the only 'java version' and is shared with scala, swift, kotlin, etc . It is populated with values:
Ideally I want to split them into three
TRAVIS_JDK_VERSION =
oraclejdk11,oraclejdk9,openjdk11,openjdk10,openjdk9: py36-javanew-allowskip
openjdk8: py36-java8-noskip
openjdk7: py36-java7-noskip
Even better would be to allow {x,y}
alternation syntax from envnames so it becomes:
TRAVIS_JDK_VERSION =
{open,oracle}jdk{9,10,11}: py36-javanew-allowskip
openjdk8: py36-java8-noskip
openjdk7: py36-java7-noskip
And with the !
syntax:
TRAVIS_JDK_VERSION =
!openjdk{7,8}: py36-javanew-allowskip
openjdk8: py36-java8-noskip
openjdk7: py36-java7-noskip
!
at the beginning of an envvar value sounds unlikely, and also undesirable/spank-me-im-stupid.
I am less confident about {
and }
in envvars.
Rather foolish now I think about it, I was expecting the following to
to be expanded to
Instead, under the covers is
'swift,objectivec,objective_c,objective-c': 'py36-swift-noskip'
The reason for my confusion is simple: that is how argvlists in tox work -- they have factors at the beginning before the
:
, and factor names cant include commas. In this case, it is envvar values before the:
, and they can include commas.Should we use the same parser? IMO, yes. It is easy to remember that these values are envvars rather than factors. It is harder to remember that they do not follow the same semantics.
The fact that envvars can (and often do) have commas is a bit troublesome, but at least
TRAVIS_LANGUAGE
doesnt contain commas, and probablyTRAVIS_*
too. But if the envvar value in Travis does contain commas, the comparison should be literal (not splitting on,
).