Grudge build/run failure on Quartz after merge with master

[MTCam]

I've seen a little bit of noise about a similar error going around. Anyone have advise on how to fix this? This is after merging emirge master.

Directory: /g/g17/mtcampbe/ceesd/Quartz/emirge2/demo/teesd/build/Testing
"SingleTests/Environment:HaveGrudge" start time: Jul 30 14:38 PDT
Output:
----------------------------------------------------------
Traceback (most recent call last):
  File "/g/g17/mtcampbe/ceesd/Quartz/emirge2/demo/teesd/Testing/SingleTests/Environment/HaveGrudge.py", li\
ne 1, in <module>
    import grudge
  File "/usr/WS1/xpacc/Users/mtcampbe/CEESD/Quartz/emirge2/demo/teesd/emirge/grudge/grudge/__init__.py", l\
ine 25, in <module>
    import grudge.symbolic as sym
  File "/usr/WS1/xpacc/Users/mtcampbe/CEESD/Quartz/emirge2/demo/teesd/emirge/grudge/grudge/symbolic/__init\
__.py", line 27, in <module>
    from grudge.symbolic.primitives import *        # noqa: F401,F403
  File "/usr/WS1/xpacc/Users/mtcampbe/CEESD/Quartz/emirge2/demo/teesd/emirge/grudge/grudge/symbolic/primit\
ives.py", line 37, in <module>
    from meshmode.discretization.connection import (
  File "/usr/WS1/xpacc/Users/mtcampbe/CEESD/Quartz/emirge2/demo/teesd/emirge/meshmode/meshmode/discretizat\
ion/__init__.py", line 30, in <module>
    from loopy.version import MOST_RECENT_LANGUAGE_VERSION
ImportError: cannot import name 'MOST_RECENT_LANGUAGE_VERSION' from 'loopy.version' (/usr/workspace/wsa/xp\
acc/Users/mtcampbe/CEESD/Quartz/emirge2.env/lib/python3.8/site-packages/loopy/version.py)
<end of output>
Test time =   1.14 sec
----------------------------------------------------------
Test Failed.

[inducer]

Should respond to the same workaround as illinois-ceesd/mirgecom#43.

[MTCam]

Thanks. I think the issue is not that I merged master; it is that the version of mirgecom (mtc/euler) I'm monitoring on the inside has not been merged with master to pick up the required changes to fix this issue.. More tangling.

[inducer]

I don't think so. illinois-ceesd/mirgecom#43 fixes something in the CI script, so unless your test scripts fish shell code out of mirgecom/.github/workflows/ci.yml, it's unlikely that the version of mirgecom will make any difference whatsoever. I'm fairly sure that what's causing our breakage is the pip release.

I'm rerunning the CI for master here, and I bet that this'll see the same failure. #52 is a test balloon for an analogous fix.

[inducer]

master run failed as predicted.

[MTCam]

ok, i think this is fine. we can have some failing tests for now when running testy.

[inducer]

#52 seems to fix it. Looking for reviewers there.

[inducer]

x-ref: pypa/pip#8667

[MTCam]

This is fixed. Is there something else we should do before closing it up?