v1.5.0rc3

[forsyth2]

Checklist

• Used a personal fork of the feedstock to propose changes
• Bumped the build number (if the version is unchanged)
• Reset the build number to 0 (if the version changed)
• Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• Ensured the license file is being packaged.

[forsyth2]

@conda-forge-admin, please rerender

[conda-forge-admin]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found it was in an excellent condition.

I do have some suggestions for making it better though...

For recipe/meta.yaml:

• ℹ️ License is not an SPDX identifier (or a custom LicenseRef) nor an SPDX license expression.

Documentation on acceptable licenses can be found here.

_{This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/18607943460. Examine the logs at this URL for more detail.}

[conda-forge-admin]

Hi! This is the friendly automated conda-forge-webservice.

I tried to rerender for you, but it looks like there was nothing to do.

_{This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/18607947847. Examine the logs at this URL for more detail.}

[forsyth2]

@andrewdnolan @xylar This PR is ready for review. This one is actually important.

New:

• E3SM-Project/zstash#393 (pins the versions for globus-sdk)
• E3SM-Project/zstash#394

From the cancelled rc2 (#17):

• E3SM-Project/zstash#390
• E3SM-Project/zstash#392

[forsyth2]

Without this, we get AttributeError: 'TransferClient' object has no attribute 'endpoint_autoactivate'. It should be possible to fix the erroring code itself, but I'm not sure how long that will take to debug. I think at this point in the testing period, we should just pin the versions like this.

[xylar]

@forsyth2, excellent instincts on this one. I agree with you on both counts. This should be fixed "properly" in zstash but not right now in the middle of Unified testing, so the upper bound is the right fix for now.

Furthermore, it tells us that we probably want to have an upper bound constraint on globus-sdk in general, so once we support 4.x, we would still have a <5.0 constraint because we know to expect breaking changes.