Skip to content

Conversation

shermansiu
Copy link
Contributor

@shermansiu shermansiu commented Aug 2, 2025

Other potential fixes

@shermansiu shermansiu requested a review from a team as a code owner August 2, 2025 19:20
@shermansiu shermansiu changed the title Make the create_feedstocks script compatible with the 2.7.0 API Make the create_feedstocks script compatible with the PyGitHub 2.7.0 API Aug 2, 2025
- The current create_feedstocks actions keep crashing (e.g. https://github.com/conda-forge/admin-requests/actions/runs/16696874176)
- The PyGitHub repo recently changed up their API in a backwards-incompatible way, which led to this problem
    - https://github.com/PyGithub/PyGithub/releases/tag/v2.7.0
@shermansiu shermansiu force-pushed the fix/update_compatible_pygithub_2_7_0 branch from 678869b to e1d6348 Compare August 2, 2025 19:25
@h-vetinari
Copy link
Member

Thanks for digging into this. For now I think I'd prefer to add <2.7 to

"pygithub>=2.1.1" \

(also in environment.yaml) and then later do an explicit changeover to the new API (who needs semantic versioning anyway? 🤦‍♂️) while raising the lower bound

@hmaarrfk
Copy link
Contributor

hmaarrfk commented Aug 3, 2025

Or at least they could havea __version__ variable like most sane projects....
PyGithub/PyGithub#3325 <-- related question

@hmaarrfk
Copy link
Contributor

hmaarrfk commented Aug 3, 2025

@h-vetinari ill try to make the Pr to limit pygithub.

But would you be ok with us using hasattr to write compatibility shims for both pre 2.7 and 2.7.

At least for the next 6 months while the API stabilizes.

@h-vetinari
Copy link
Member

But would you be ok with us using hasattr to write compatibility shims for both pre 2.7 and 2.7.

Sure! My point was that we should only use the bare pre-2.7 or post-2.7 API, if we accompany it with version bounds in the environment. But if you write a shim that works both before and after, even better!

@h-vetinari
Copy link
Member

Thanks for digging into this. For now I think I'd prefer to add <2.7

This would still be the correct fix to stop the bleeding IMO, and then follow up with #1602 which can remove the limit again

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants