testscript: add support for the txtar file extension #126
Comments
|
I personally vote for option 1 - to just change the behavior. I'd be incredibly surprised if it broke any existing programs/tests. I understand the current semantics to be "load all txtar files in the provided directory", not "load all files in the provided directory with the txt extension". Arguably, using |
|
As a bit of an update: I propose that the tools use Then none of the existing users should break, new code would naturally gravitate towards using @rogpeppe @myitcv thoughts? I'd like to make this transition happen in my repos and am happy to implement it here :) |
|
I'm happy with that suggestion. |
|
Yeah, I've thought for a while that |
mvdan
changed the title
For backwards compatibility, both testscript and goproxytest, which used to glob on `*.txt`, now look for both file extensions. Note that this required a bit of a refactor in testscript, as we cannot use a single glob expression to accomplish this. Code which produces files, such as txtar-addmod, now produces `*.txtar` rather than `*.txt`. Similarly, the public docs now use `*.txtar` too. Note that we leave many txt files in tests untouched; it's unnecessary to change them given the backwards compatibility, and it has zero benefit to the user as they aren't public. Moreover, the diff churn would make this patch harder to review. If a future version of go-internal only supports txtar extensions, then it could replace all of those extensions accordingly. Fixes rogpeppe#126.
|
PR ready :) |
For backwards compatibility, both testscript and goproxytest, which used to glob on `*.txt`, now look for both file extensions. Note that this required a bit of a refactor in testscript, as we cannot use a single glob expression to accomplish this. Code which produces files, such as txtar-addmod, now produces `*.txtar` rather than `*.txt`. Similarly, the public docs now use `*.txtar` too. Note that we leave many txt files in tests untouched; it's unnecessary to change them given the backwards compatibility, and it has zero benefit to the user as they aren't public. Moreover, the diff churn would make this patch harder to review. If a future version of go-internal only supports txtar extensions, then it could replace all of those extensions accordingly. Fixes rogpeppe#126.
For backwards compatibility, both testscript and goproxytest, which used to glob on `*.txt`, now look for both file extensions. Note that this required a bit of a refactor in testscript, as we cannot use a single glob expression to accomplish this. Code which produces files, such as txtar-addmod, now produces `*.txtar` rather than `*.txt`. Similarly, the public docs now use `*.txtar` too. Note that we leave many txt files in tests untouched; it's unnecessary to change them given the backwards compatibility, and it has zero benefit to the user as they aren't public. Moreover, the diff churn would make this patch harder to review. If a future version of go-internal only supports txtar extensions, then it could replace all of those extensions accordingly. Fixes rogpeppe#126.
For backwards compatibility, both testscript and goproxytest, which used to glob on `*.txt`, now look for both file extensions. Note that this required a bit of a refactor in testscript, as we cannot use a single glob expression to accomplish this. Code which produces files, such as txtar-addmod, now produces `*.txtar` rather than `*.txt`. Similarly, the public docs now use `*.txtar` too. Note that we leave many txt files in tests untouched; it's unnecessary to change them given the backwards compatibility, and it has zero benefit to the user as they aren't public. Moreover, the diff churn would make this patch harder to review. If a future version of go-internal only supports txtar extensions, then it could replace all of those extensions accordingly. Fixes #126.
Currently,
testscriptis hard-coded to only look for.txtfiles.This is unfortunate, because
.txtaris a more descriptive extension that would better lend itself to automatic syntax highlighting (on GitHub) etc.Opening this issue to capture the options for changing/extending this:
.txtand.txtartestscript.ParamsThe text was updated successfully, but these errors were encountered: