make compatible with non-coupling-enabled versions of grudge v3

[matthiasdiener]

Followup of #898.

TODO:

• needs Restore loop inference fallback inducer/arraycontext#269
• undo changing branches to main (undo 596894d)

---

Questions for the review:

• Is the scope and purpose of the PR clear?
  • The PR should have a description.
  • The PR should have a guide if needed (e.g., an ordering).
• Is every top-level method and class documented? Are things that should be documented actually so?
• Is the interface understandable? (I.e. can someone figure out what stuff does?) Is it well-defined?
• Does the implementation do what the docstring claims?
• Is everything that is implemented covered by tests?
• Do you see any immediate risks or performance disadvantages with the design? Example: what do interface normals attach to?

[matthiasdiener]

This is ready for a first look @majosm @MTCam @inducer. The production tests probably have no chance of succeeding (but I think this isn't the goal).

[MTCam]

I don't have a problem with anything being done here, except the hamstringing of the prediction tests. If prediction tests can't be run, then nothing can stop us from checking things in that break prediction - which has caused us great trouble multiple times in the not-too-distant past.

[matthiasdiener]

I don't have a problem with anything being done here, except the hamstringing of the prediction tests. If prediction tests can't be run, then nothing can stop us from checking things in that break prediction - which has caused us great trouble multiple times in the not-too-distant past.

Just to clarify, this PR currently includes changing the production branches of depending packages to main (596894d). This is temporary, to demonstrate that the non-coupling-needing tests can pass. This will be reversed in case this PR is going to be merged.

[MTCam]

I don't have a problem with anything being done here, except the hamstringing of the prediction tests. If prediction tests can't be run, then nothing can stop us from checking things in that break prediction - which has caused us great trouble multiple times in the not-too-distant past.

Just to clarify, this PR currently includes changing the production branches to main (596894d). This is temporary, to demonstrate that the non-coupling-needing tests can pass. This will be reversed in case this PR is going to be merged.

Ah, I see now. So is the plan that external packages can do their "upstream mirgecom tests" in CI by using run-examples.sh, and only compatible tests will be run?

[matthiasdiener]

I don't have a problem with anything being done here, except the hamstringing of the prediction tests. If prediction tests can't be run, then nothing can stop us from checking things in that break prediction - which has caused us great trouble multiple times in the not-too-distant past.

Just to clarify, this PR currently includes changing the production branches to main (596894d). This is temporary, to demonstrate that the non-coupling-needing tests can pass. This will be reversed in case this PR is going to be merged.

Ah, I see now. So is the plan that external packages can do their "upstream mirgecom tests" in CI by using run-examples.sh, and only compatible tests will be run?

Yes, run-examples.sh, or pytest.

[MTCam]

I don't have a problem with anything being done here, except the hamstringing of the prediction tests. If prediction tests can't be run, then nothing can stop us from checking things in that break prediction - which has caused us great trouble multiple times in the not-too-distant past.

Just to clarify, this PR currently includes changing the production branches to main (596894d). This is temporary, to demonstrate that the non-coupling-needing tests can pass. This will be reversed in case this PR is going to be merged.

Ah, I see now. So is the plan that external packages can do their "upstream mirgecom tests" in CI by using run-examples.sh, and only compatible tests will be run?

Yes, run-examples.sh, or pytest.

I don't think it can be "or". Upstream pkg's dowstream mirgecom tests should include the examples, at least, if not exclusively.

[matthiasdiener]

This is ready for review. The Production CI error is due to a merge issue.

[MTCam]

👍