choosetests: return a NamedTuple (instead of a Tuple), to make it easier to add more information in the future

[DilumAluthge]

Currently, the choosetests function returns a Tuple.

This pull request modifies the choosetests function so that it returns a NamedTuple instead. With this change, if in the future we decide to add more return values, we can do so without breaking existing uses of the choosetets function.

[aviatesk]

I suggest you switch to the config = choosetests(…) and config.tests pattern at every callsite. We also want to change the docstring accordingly.

[DilumAluthge]

We also want to change the docstring accordingly.

Done!

[DilumAluthge]

I suggest you switch to the config = choosetests(…) and config.tests pattern at every callsite. We also want to change the docstring accordingly.

Hmmm, any particular reason why? This seems like a lot of code churn. And the current form (tests, net_on, exit_on_error, use_revise, seed = choosetests(ARGS)) should continue to work fine, right?

[aviatesk]

And the current form (tests, net_on, exit_on_error, use_revise, seed = choosetests(ARGS)) should continue to work fine, right?

yeah, but it also holds for the current Tuple return type: e.g. a, b = (1, 2, 3) # assume 3 is added later.
I thought the purpose of this PR is to stop splatting the return value at callsite (which requires us to understand the order of tuple), but rather use the computed options with explicit field access instead ?

[DilumAluthge]

I thought the purpose of this PR is to stop splatting the return value at callsite (which requires us to understand the order of tuple), but rather use the computed options with explicit field access instead ?

Oh, I see what you're getting at. Yeah that was the purpose of this PR.

[DilumAluthge]

What if we instead switch to destructuring the named tuple, i.e. (; tests, net_on, exit_on_error, use_revise, seed) = choosetests(ARGS)?

It's more concise. And as far as I can tell, this form does not require us to know about the order of the tuple, right?

[vtjnash]

We'll probably still need to preserve the order in the future, but this will likely make it easier for folks to use, particularly for new additions