Fix "install from conda forge" CI broken by release 3.10.0

[glatterf42]

Unfortunately, our release 3.10.0 broke our own "install from conda forge" CI again. This PR will eventually fix that.

We see this error upon test collection in the CI run:

 ImportError while importing test module 'D:\a\_actions\iiasa\actions\main\setup-conda\Anaconda3\envs\testenv\Lib\site-packages\message_ix\tests\tools\test_sankey.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
D:\a\_actions\iiasa\actions\main\setup-conda\Anaconda3\envs\testenv\Lib\site-packages\message_ix\tools\sankey.py:5: in <module>
    from pyam.str import get_variable_components
E   ModuleNotFoundError: No module named 'pyam.str'

During handling of the above exception, another exception occurred:
D:\a\_actions\iiasa\actions\main\setup-conda\Anaconda3\envs\testenv\Lib\importlib\__init__.py:88: in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
D:\a\_actions\iiasa\actions\main\setup-conda\Anaconda3\envs\testenv\Lib\site-packages\message_ix\tests\tools\test_sankey.py:7: in <module>
    from message_ix.tools.sankey import map_for_sankey
D:\a\_actions\iiasa\actions\main\setup-conda\Anaconda3\envs\testenv\Lib\site-packages\message_ix\tools\sankey.py:7: in <module>
    from pyam.utils import get_variable_components
E   ImportError: cannot import name 'get_variable_components' from 'pyam.utils' (D:\a\_actions\iiasa\actions\main\setup-conda\Anaconda3\envs\testenv\Lib\site-packages\pyam\utils.py)

We introduced the sankey tool in this release and it already includes a clause that tries to handle older versions of pyam (that adjusted the location from which to import get_variable_components. However, the CI run currently installs pyam 0.7.0, which was released more than 4.5 years ago, for some reason.

Unfortunately, conda doesn't seem to offer any option to explain its dependency resolution process. I didn't find any reason when comparing version 0.7.0 and 0.8.0 of pyam: the pytest dependency received a pin, but that didn't make it to the conda-force build recipe. In fact, the current recipe only contains a pin of numpy to < 2.0, which I would not expect to effect anything from four years ago.

I'll keep on looking for a reason, but in the meantime, this PR attempts to install pyam 3.0.0 explicitly in the hopes that this will either work or yield some details on why not.

How to review

• Read the diff and note that the CI checks all pass.

PR checklist

• Continuous integration checks all ✅
• Add or expand tests; coverage checks both ✅
• [ ] Add, expand, or update documentation. Just CI
• [ ] Update release notes. Just CI.
• Rebase removing "TEMPORARY" commits.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 95.6%. Comparing base (42ef4e1) to head (c729222).

Additional details and impacted files

@@          Coverage Diff          @@
##            main    #919   +/-   ##
=====================================
  Coverage   95.6%   95.6%           
=====================================
  Files         48      48           
  Lines       4401    4401           
=====================================
  Hits        4211    4211           
  Misses       190     190           

[glatterf42]

Looks like this did indeed yield the error:
This is the error message we can see:

 LibMambaUnsatisfiableError: Encountered problems while solving:
  - nothing provides _python_rc needed by python-3.12.0rc3-rc3_h30d4d87_1_cpython

Could not solve for environment specs
The following packages are incompatible
├─ pin on python 3.13.* =* * is installable and it requires
│  └─ python =3.13 *, which can be installed;
└─ pyam =3.0.0 * is not installable because it requires
   └─ python >=3.10,<3.13 * but there are no viable options
      ├─ python [3.10.0|3.10.1|...|3.12.9] conflicts with any installable versions previously reported;
      └─ python [3.12.0rc3|3.13.0rc1|3.13.0rc2|3.13.0rc3] would require
         └─ _python_rc =* *, which does not exist (perhaps a missing channel).

Pins seem to be involved in the conflict. Currently pinned specs:
 - python=3.13

This struck me as odd because the other tests using 3.13 are passing fine, in particular test_sankey, which left only one option. And indeed, looking at the current pyam recipe again, I found that they forgot to shift the pin of Python 3.13 even though pyam 3.0.0 already supports it on PyPi:

https://github.com/conda-forge/pyam-feedstock/blob/main/recipe/meta.yaml#L26

Now, on to fixing the recipe in their conda-forge feedstock. I'm just not sure if a PR there will already update the available version so that conda recognizes 3.0.0 for Python 3.13.

[glatterf42]

conda-forge/pyam-feedstock#69 will fix this issue, after which we can use this PR or the schedule tests to confirm that everything works again. Note that everything should work fine without any change to main, so this PR should not be merged either way.

[glatterf42]

Through re-running the tests, I found that the same problems exists for the ixmp4 feedstock, which still blocks pyam 3.0.0 to be used. conda-forge/ixmp4-feedstock#29 should fix that.