-
Notifications
You must be signed in to change notification settings - Fork 8
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
Use scikit build instead of setup.py #103
base: main
Are you sure you want to change the base?
Conversation
bfadd4b
to
e3cc8be
Compare
workflow_run: | ||
workflows: ["HELICS Version Update"] | ||
branches: [main] | ||
types: | ||
- completed |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the idea of running it as part of the HELICS Version Update tag -- I wonder if instead the update workflow could call this workflow as a step, and then if this workflow succeeds + tests pass, the update workflow could create a new version tag/release in the repository that will trigger running this workflow to actually do the real PyPI build + release for the new version.
Reuseable workflow/workflow_call docs: https://docs.github.com/en/actions/sharing-automations/reusing-workflows#calling-a-reusable-workflow
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How does a new branch gets tagged right now? This doesn't happen in update helics version, right?
If I understand you correctly, you mean
- Update HELICS version gets run.
- Run tests and build python package
- Make a tag if tests pass
- Upload repository by calling pythonpackage agains.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Someone has to follow the release checklist and create the pyhelics release: GMLC-TDC/HELICS#2661
set(HELICS_ZMQ_SUBPROJECT ON) | ||
set(HELICS_ZMQ_FORCE_SUBPROJECT ON) | ||
set(HELICS_ENABLE_ZMQ_CORE ON) # TODO: vendor libzmq similar to other 3rd party libraries | ||
set(HELICS_DISABLE_BOOST OFF) # TODO: headers are just needed to compile, maybe tell users to have it installed as prereq for building from source? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should users to have it installed as a pre-requisite for buidling from source. I think we need to update the pyproject.toml file to exclude the copy of boost that was downloaded (or have cibuildwheel on Linux stick it in a folder outside of the repository clone). A copy of Boost has made its way into the current source dist, making it take up about 250MB compressed -- or 1+ GB uncompressed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've moved it to /tmp/boost. I'm still not sure why it got included in the sdist.
Co-authored-by: Ryan Mast <3969255+nightlark@users.noreply.github.com>
8aaeac0
to
b033b84
Compare
setuptools-scm
does not seem to be required, but @nightlark mentioned using the dynamic-version tag. What this means is thathelics/_version.py
has been deleted from git, and instead it is automatically generated from the latest git tag. This makes.github/workflows/update-helics.yml
redundant.Remaining items