Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Disabling PyPy #201

Open
jakirkham opened this issue Mar 30, 2022 · 9 comments
Open

Disabling PyPy #201

jakirkham opened this issue Mar 30, 2022 · 9 comments

Comments

@jakirkham
Copy link
Member

Recently the Dask Community decided to drop PyPy support. Given this, what is the best way for us to disable PyPy support? We can add a skip to the recipe to disable these builds.

Though as discussed in issues ( regro/cf-scripts#1044 ) ( regro/cf-scripts#1386 ), we don't have a great way to opt-out of migrations and this can have downstream effects.

Given this, am raising this issue to solicit feedback ( cc @conda-forge/core ) on how we should handle this here and the proceed with next steps.

cc @jrbourbeau @mrocklin

@jakirkham
Copy link
Member Author

jakirkham commented Mar 30, 2022

Admittedly this may be less of an issue given we were able to move to noarch somewhat recently ( #199 ) (though this could always change in the future if selectors are needed again). Also not sure if there is a good way for noarch packages to error when installing with pypy

@beckermr
Copy link
Member

If you opt out then downstream packages that need pypy and dask have no choice. Mark the prs as drafts.

@jakirkham
Copy link
Member Author

Think we added PyPy previously ( #155 ). So Idk if there is a way to back that out as it were

@hmaarrfk
Copy link

This might also be tied to accendental merges of PRs for migrations:
conda-forge/lintel-feedstock#15 (comment)

@mattip
Copy link

mattip commented Mar 30, 2022

Is supporting pypy such a burden that it is worth actively blocking? Has it caused problems?

@jakirkham
Copy link
Member Author

@mattip probably better to have that discussion in issue ( dask/distributed#5681 )

@hmaarrfk
Copy link

to be honest. with the pypy38 migration, now might be the best time to simply delete the yaml file.

@hmaarrfk
Copy link

Users will still be able to use the old version.

@mrocklin
Copy link
Contributor

mrocklin commented Oct 11, 2022 via email

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

No branches or pull requests

5 participants