Iris, pandas not importing in conda/analysis3-26.03

Description of request:

I’m unable to import iris or pandas in python on a compute node. (Iris is failing due to the dependency on pandas.) The last time I did so successfully was before gadi’s maintenance period on 5/5/26. It works okay on a login node.

Environment:

I am ssh’ing directly to a login node, not using ARE. To access a compute node interactively I use qsub -I -q normalbw ...
I tried both analysis3-2026.03 and analysis3-2026.01.

What executed:

In python, import iris; import pandas

Actual results:

>>> import pandas
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/g/data/xp65/admin/analysis3/sitecustomize.py", line 72, in tracking_import
    mod = _real_import(name, globals, locals, fromlist, level)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/g/data/xp65/public/apps/med_conda/envs/analysis3-26.01/lib/python3.11/site-packages/pandas/__init__.py", line 139, in <module>
    from pandas import testing
  File "/g/data/xp65/admin/analysis3/sitecustomize.py", line 72, in tracking_import
    mod = _real_import(name, globals, locals, fromlist, level)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/g/data/xp65/public/apps/med_conda/envs/analysis3-26.01/lib/python3.11/site-packages/pandas/testing.py", line 6, in <module>
    from pandas._testing import (
  File "/g/data/xp65/admin/analysis3/sitecustomize.py", line 72, in tracking_import
    mod = _real_import(name, globals, locals, fromlist, level)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/g/data/xp65/public/apps/med_conda/envs/analysis3-26.01/lib/python3.11/site-packages/pandas/_testing/__init__.py", line 405, in <module>
    cython_table = pd.core.common._cython_table.items()
                   ^^^^^^^
AttributeError: partially initialized module 'pandas' has no attribute 'core' (most likely due to a circular import)

Expected results:

Not to fail.

Additional info:

Heya Susan,

I’ve had a look and I think this is probably pollution from packages in .local as I can’t reproduce the bug in 26.01 or 26.05:

ct1163 in 🌐 gadi-login-05 in ~ via 🐍 v3.11.14 via 🅒 analysis3-26.01 
❯ python -c "import pandas; import iris"


ct1163 in 🌐 gadi-login-05 in ~ via 🐍 v2.7.18 via 🅒 analysis3-26.01 took 12s 
❯ module unload conda/analysis3-26.01 && module load conda/analysis3-26.05
Unloading conda/analysis3-26.01
  Unloading useless requirement: singularity
Loading conda/analysis3-26.05
  Loading requirement: singularity

ct1163 in 🌐 gadi-login-05 in ~ via 🐍 v3.12.13 via 🅒 analysis3-26.05 
❯ python -c "import pandas; import iris"

Can you tell me what tree -L 1 ~/.local/lib/python3.??/ turfs up?


Circular reference issues are generally/commonly the result of internal refactoring in packages. I suspect what’s happened here is that you have a mismatch between the expected pandas & iris versions on your Python path.

This should not (not to say it doesn’t occasionally :sweat_smile:) happen as package authors will generally specify compatible versions, so the solved conda environment has guardrails ensuring this sort of thing doesn’t happen. If things get installed into .local accidentally (typically if you run $ pip install $SOMETHING), these guardrails can get overwritten.

Hi Charles,
I get

/home/548/sjr548/.local/lib/python3.??/ [error opening dir]

0 directories, 0 files

on both a login node and on the compute node.

Huh, that’s really weird.

Can you run

  • python -c "import pandas; print(pandas.__file__); print(pandas.__version__)"
    and
  • python -c "import iris; print(iris.__file__); print(iris.__version__)"

for me please? (and post the output in here)

/g/data/xp65/public/apps/med_conda/envs/analysis3-26.03/lib/python3.12/site-packages/pandas/__init__.py
2.3.3

and

/g/data/xp65/public/apps/med_conda/envs/analysis3-26.03/lib/python3.12/site-packages/iris/__init__.py
3.14.1

Apparently October last year I renamed .local/lib to .local/hidelib, which would account for why this directory wasn’t found. Probably because I was getting conflicts! Unclear why or if this is causing an issue today, or maybe .local is not a factor.

Now there’s a plot twist - I get the exact same results, but no circular imports:

ct1163 in 🌐 gadi-login-04 in ~ via 🐍 v3.11.14 via 🅒 analysis3-26.01 
❯ module load conda/analysis3-26.03
Loading conda/analysis3-26.03
  Loading requirement: singularity

ct1163 in 🌐 gadi-login-04 in ~ via 🐍 v3.12.13 via 🅒 analysis3-26.03 
❯ python -c "import pandas; print(pandas.__file__); print(pandas.__version__)"
/g/data/xp65/public/apps/med_conda/envs/analysis3-26.03/lib/python3.12/site-packages/pandas/__init__.py
2.3.3

ct1163 in 🌐 gadi-login-04 in ~ via 🐍 v3.12.13 via 🅒 analysis3-26.03 took 3s 
❯ python -c "import iris; print(iris.__file__); print(iris.__version__)"
/g/data/xp65/public/apps/med_conda/envs/analysis3-26.03/lib/python3.12/site-packages/iris/__init__.py
3.14.1

ct1163 in 🌐 gadi-login-04 in ~ via 🐍 v3.12.13 via 🅒 analysis3-26.03 took 7s 
❯ python -c "import iris; import pandas"

can you try importing the two again and let me know if it’s magically resolved itself? I’m crossing my fingers and hoping there’s some weird Gadi gremlins…

Ahh… let me do some googling, it’s possible that hidelib is still getting dragged into the environment somehow.

Your theory of gremlins is correct! Now it’s working fine.
I haven’t changed anything, so not sure how to account for this.

Phew!

I had a look at the CPython docs & it seems like ~.local/hidelib/python3.XX won’t get dragged in without some very intentional configuration on your part, so I think the .local guess from me was a red herring.

We’ve been experimenting with some with some tooling to detect which libraries people need in analysis3. It’s possible (probable?) that this is the source of the gremlins, so I’ll look into that - but I think this is unlikely to happen to you again.


I have a sneaking suspicion based on what we’ve seen here that there may be some initialisation issues in that code, so for anyone else reading this down the line, please just have a second crack at importing the relevant packages!