spacetelescope / action-publish_to_pypi Goto Github PK

1. Would be nice to have some examples of what makes a good version and a bad one.
2. What if a PyPI package of that name exists already but not ours?
3. "Whenever a new release with a semver-compliant tag is made on Github from the repository, ..." -- So, not only the tag needs to be semver, but the person need to push the "edit tag" and then "publish release" buttons, right? This should be made clearer.
4. "an e-mail message" -- Whose email will it use? Is it customizable, say, to point to a mailing list?
5. Nice to have: Screenshots to go with the instructions.

github looks to have deprecated macos-10.15 runners in Aug 2022.
https://github.blog/changelog/2022-07-20-github-actions-the-macos-10-15-actions-runner-image-is-being-deprecated-and-will-be-removed-by-8-30-22/

I have a long running build_wheels job that has been stalled for a few hours to build the macos-10.15 wheel that I think is hanging because these runners no longer exist. I think this line
https://github.com/spacetelescope/action-publish_to_pypi/blob/master/.github/workflows/workflow.yml#L36
needs to get updated to macos-11 or macos-latest?

I have a job that is stalled, I believe because the macos-10.15 runners don't exist.
https://github.com/spacetelescope/romanisim/actions/runs/5091745247/jobs/9152188689

Sorry if I'm way off base---I don't really know anything about github actions / runners / pypi / wheels / ..., but the breadcrumbs looked pretty clear to me. I am confused though about what I'm doing differently to see this.

In the docs or in a separate examples dir, it would be very useful to have an example to show a simple implementation of the new workflows added in #14.

The pep517 package is deprecated.

https://pypi.org/project/pep517/

Use build instead.

https://pypi.org/project/build/

A recent update to stistools tagged as 1.4.3 got published to PyPI as version 0.0.0 (at the bottom).

The github actions log shows:

2022-12-22T19:21:10.6494752Z Version validation argument: refs/tags/1.4.3
2022-12-22T19:21:10.6495019Z Tag: 1.4.3
2022-12-22T19:21:10.6495221Z Tag is a valid semver value.
2022-12-22T19:21:10.6533239Z Prepare for publication...
...
2022-12-22T19:21:11.4063530Z Uploading distributions to https://upload.pypi.org/legacy/
2022-12-22T19:21:11.4064081Z Uploading stistools-0.0.0.tar.gz
2022-12-22T19:21:11.4064238Z 
2022-12-22T19:21:12.8159664Z   0%|          | 0.00/112k [00:00<?, ?B/s]
2022-12-22T19:21:12.8212836Z 100%|##########| 112k/112k [00:01<00:00, 81.4kB/s]
2022-12-22T19:21:12.8213027Z 
2022-12-22T19:21:12.8213098Z View at:
2022-12-22T19:21:12.8213349Z https://pypi.org/project/stistools/0.0.0/

Any idea what's going on here?

cc: @stscirij

When running the validate action when publishing costools 1.2.6, the following issue occurs:
https://github.com/spacetelescope/costools/actions/runs/4104843972/jobs/7081101370

Version validation argument: 
Tag: 
Traceback (most recent call last):
  File "<stdin>", line 9, in <module>
  File "/opt/hostedtoolcache/Python/3.8.16/x64/lib/python3.8/site-packages/semver.py", line 726, in parse
    raise ValueError("%s is not valid SemVer string" % version)
ValueError:  is not valid SemVer string

It appears that this should be $GITHUB_REF, but the variable is empty:

PyPA has it's own official github action for doing uploads to PyPI now.

https://github.com/pypa/gh-action-pypi-publish

Might be worth comparing to this one.

This would be useful for cases where a project's tagging scheme does not conform to the strict semver spec, but publication to PyPI is still desired.

Is there a way I can skip a platform when building wheels for a specific repository?
More specifically, is there a way to pass a configuration option to cibuildwheel skipping a platform, e.g.

CIBW_SKIP: "*-manylinux_i686"

🤷 😉 😬