This is somewhat related to issue #17220 and also to #17222: Assuming that our Regex module continues to be a standard (rather than package) module and based on RE2, should we should consider changing the CHPL_REGEXP environment variable to CHPL_RE2 and the values to be bundled vs. none, to be more similar to other third-party packages we rely upon? The current CHPL_REGEXP variable with values re2 and none suggests to me that one could plug in other packages rather than re2, yet I don't know that any of us expect that to be supported or supportable (?).
:+1: — Brad argues that this is the most flexible approach in that:
CHPL_REGEX says "what technology should be used to implement Regex?" where today's answers are re2 or none, but other technologies like pcre, etc. could be added in the future
CHPL_RE2 says "if re2 was selected, where will we find it?", where today's answers are bundled or none but ultimately we could support system if/when our patches are merged upstream or we stop relying on them
✅ Future-proof
✅ Similar to what we do for for other cases (e.g., CHPL_COMM/CHPL_GASNET)
❌ Requires implementing two variables w/ 4 options to describe the 2 options we support today, so it's needless work (especially for scripts and makefiles)
:heart: — This could be considered a stepping stone toward :+1: that can be viewed as assuming/hardcoding CHPL_REGEX=re2
✅ Only requires implementing one variable
❌ Requires changing CHPL_REGEXP to CHPL_RE2, hard-coding RE2 in the name, at least for some time
(Brad's rebuttal: that choice of name is intentional / by design, so I don't see why this is a negative)
❌ May be harder for users to transition from CHPL_REGEXP to CHPL_RE2 than to CHPL_REGEX
(Brad's rebuttal: users almost never set this variable in practice because it's correctly inferred for them).
🎉 — This could be considered a stepping stone toward :+1: that can be viewed as assuming/hardcoding CHPL_RE2=bundled
✅ Only requires implementing one variable
✅ Only requires renaming the environment variable CHPL_REGEXP to CHPL_REGEX, with the rest of the code remaining mostly the same
:rocket: — This can be considered as combining the best of :heart: and :tada: by renaming the environment variable name from CHPL_REGEXP to CHPL_REGEX, but also allowing the values bundled or none to be specified, but not disallowing specific packages like re2 or pcre to be specified in the future, in which case which version to use (bundled, system) can be specified by a package-specific variable like CHPL_RE2 in the future, which is similar to :+1:
✅ Only requires implementing one variable
✅ Does not preclude adding CHPL_RE2 or similar variables in the future, to specify which version of RE2 to use
❌ Allows for the first time a general Chapel feature macro like CHPL_REGEX to take on values like bundled, when values like bundled have historically only been allowed for specific software packages
Right now the Regex module is tied to a patched version of RE2, and so unless the interface of Regex can be flexible enough to handle unmodified versions of RE2, PCRE, etc., it is likely that the only choices available will be bundled (re2) and none.
This is somewhat related to issue #17220 and also to #17222: Assuming that our Regex module continues to be a standard (rather than package) module and based on RE2, should we should consider changing the
CHPL_REGEXPenvironment variable toCHPL_RE2and the values to bebundledvs.none, to be more similar to other third-party packages we rely upon? The currentCHPL_REGEXPvariable with valuesre2andnonesuggests to me that one could plug in other packages rather thanre2, yet I don't know that any of us expect that to be supported or supportable (?).Options discussed below: :heart: CHPL_RE2 = bundled | none 🎉 CHPL_REGEX = re2 | none 🚀 CHPL_REGEX = bundled | none :+1: CHPL_REGEX = re2 | none && CHPL_RE2 = bundled | none
Rationale for the options:
:+1: — Brad argues that this is the most flexible approach in that:
CHPL_REGEXsays "what technology should be used to implement Regex?" where today's answers arere2ornone, but other technologies likepcre, etc. could be added in the futureCHPL_RE2says "if re2 was selected, where will we find it?", where today's answers arebundledornonebut ultimately we could supportsystemif/when our patches are merged upstream or we stop relying on them ✅ Future-proof ✅ Similar to what we do for for other cases (e.g., CHPL_COMM/CHPL_GASNET) ❌ Requires implementing two variables w/ 4 options to describe the 2 options we support today, so it's needless work (especially for scripts and makefiles):heart: — This could be considered a stepping stone toward :+1: that can be viewed as assuming/hardcoding
CHPL_REGEX=re2✅ Only requires implementing one variable ❌ Requires changing
CHPL_REGEXPtoCHPL_RE2, hard-codingRE2in the name, at least for some time(Brad's rebuttal: that choice of name is intentional / by design, so I don't see why this is a negative) ❌ May be harder for users to transition from
CHPL_REGEXPtoCHPL_RE2than toCHPL_REGEX(Brad's rebuttal: users almost never set this variable in practice because it's correctly inferred for them).🎉 — This could be considered a stepping stone toward :+1: that can be viewed as assuming/hardcoding
CHPL_RE2=bundled✅ Only requires implementing one variable ✅ Only requires renaming the environment variable
CHPL_REGEXPtoCHPL_REGEX, with the rest of the code remaining mostly the same:rocket: — This can be considered as combining the best of :heart: and :tada: by renaming the environment variable name from
CHPL_REGEXPtoCHPL_REGEX, but also allowing the valuesbundledornoneto be specified, but not disallowing specific packages likere2orpcreto be specified in the future, in which case which version to use (bundled,system) can be specified by a package-specific variable likeCHPL_RE2in the future, which is similar to :+1:CHPL_RE2or similar variables in the future, to specify which version ofRE2to use ❌ Allows for the first time a general Chapel feature macro likeCHPL_REGEXto take on values likebundled, when values likebundledhave historically only been allowed for specific software packagesRight now the
Regexmodule is tied to a patched version ofRE2, and so unless the interface ofRegexcan be flexible enough to handle unmodified versions ofRE2,PCRE, etc., it is likely that the only choices available will bebundled(re2) andnone.