Pin importlib_metadata <8

[ehogan]

Description

• Closes #3699

• Link to documentation:

• • *

Before you get started

• [x] ☝ Create an issue to discuss what you are going to do

Checklist

It is the responsibility of the author to make sure the pull request is ready to review. The icons indicate whether the item will be subject to the 🛠 Technical or 🧪 Scientific review.

• [x] 🛠 This pull request has a descriptive title
• [x] 🛠 Code is written according to the code quality guidelines
• [x] 🛠 Tests run successfully
• [x] 🛠 Any changed dependencies have been added or removed correctly
• [x] 🛠 All checks below this pull request were successful

---

To help with the number of pull requests:

• 🙏 We kindly ask you to review two other open pull requests in this repository

[bouweandela]

Is this needed for the main branch? I understood that importlib_metadata version 8 is incompatible with esmpy < 8.6, but in the main branch esmpy is pinned to >= 8.6 since #3643.

[ehogan]

Is this needed for the main branch? I understood that importlib_metadata version 8 is incompatible with esmpy < 8.6, but in the main branch esmpy is pinned to >= 8.6 since #3643.

Ah, yes, since importlib_metadata will be removed from ESMValCore after this release (see my comment on #3699), it makes sense to add this change to the release branch. I have updated the PR to target the release branch 👍

[ehogan]

Is this needed for the main branch? I understood that importlib_metadata version 8 is incompatible with esmpy < 8.6, but in the main branch esmpy is pinned to >= 8.6 since #3643.

Ah, yes, since importlib_metadata will be removed from ESMValCore after this release (see my comment on #3699), it makes sense to add this change to the release branch. I have updated the PR to target the release branch 👍

Although, I just realised that we'll need to merge the ESMValTool release branch back into main, so this change will end up on main anyway, unless I revert the change on the release branch after it is tagged but before the merge to main? 🤔

[bouweandela]

Did you not tag a release candidate before creating the release branch?

[ehogan]

Did you not tag a release candidate before creating the release branch?

Not for ESMValTool, because I thought a release candidate wasn't created for ESMValTool? (There aren't any release candidates listed at https://github.com/ESMValGroup/ESMValTool/releases.)

[bouweandela]

Not previously, but it would be nice to start doing that to avoid the merge the release branch back into the main branch issue. Let's do it next release then and merge back for now.

[ehogan]

It is possible to do it for this release; I would tag main before the esmpy PR I reverted, recreate the release branch from that tag, then cherry-pick everything after the esmpy PR (14 PRs) onto the release branch. Happy to do that if you'd prefer? 😊

[bouweandela]

Yes, that would be great, if it's not too much work, you seem busy enough as it is.

[bouweandela]

I think you could also tag the current main branch, create the release branch, and cherry pick c7abf572721e1e73abf6aa6c5b45f8f92d92fbe3 and c0ab625aadac8a4330efa6b0158a6aa2e61bc052 into it.

[ehogan]

I think you could also tag the current main branch, create the release branch, and cherry pick c7abf57 and c0ab625 into it.

Ok, that sounds good, I'll try that 👍