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

rework workflows for consistency with other repos #250

Draft
wants to merge 19 commits into
base: main
Choose a base branch
from

Conversation

altendky
Copy link
Contributor

@altendky altendky commented Jan 28, 2023

Draft for:

  • review TODO:s

@altendky
Copy link
Contributor Author

So aside from the general tidying and such that I need to do... @arvidn and @richardkiss (or even @cmmarslender), what do you think of sticking with ABI3 wheels vs. building separately for each Python version? My main interest in considering dropping ABI3 is just for consistency across our workflow definitions. There's enough complexity and variation between projects without having the main matrix also being different. Though, I also feel a bit silly with that. But I'm not sure that ABI3 really brings us a lot of value particularly. Mostly that the wheels would be forward compatible with future Python versions, what else? But I don't think that publishing a wheel is a big cost for us and we really ought to test the new Python version first anyways.

So, how do you all feel about this?

@arvidn
Copy link
Contributor

arvidn commented Feb 13, 2023

at least chia_rs depends on the buffer protocol API, which is not part of abi3, but is part of all python versions we support. I don't have a strong opinion about standardizing on one or the other across wheels. Though, the wheel built from this repository (clvm_rs) is only used by clvm_tools's brun command, nothing else as far as I know. Other parts of clvm_tools is being replaced by clvm_tools_rs as far as I know.

@richardkiss
Copy link
Contributor

I strongly believe that if we can use ABI3, we should do so. Why would we want to produce more artifact outputs when we can get away with producing fewer?

@altendky
Copy link
Contributor Author

My main interest in considering dropping ABI3 is just for consistency across our workflow definitions. There's enough complexity and variation between projects without having the main matrix also being different. Though, I also feel a bit silly with that. But I'm not sure that ABI3 really brings us a lot of value particularly. Mostly that the wheels would be forward compatible with future Python versions, what else?

@github-actions
Copy link

'This PR has been flagged as stale due to no activity for over 60
days. It will not be automatically closed, but it has been given
a stale-pr label and should be manually reviewed.'

@altendky altendky self-assigned this Apr 21, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants