Codecov Report

Merging #603 (b5621e8) into main (a179fb5) will not change coverage.
The diff coverage is n/a.

❗ Current head b5621e8 differs from pull request most recent head 2080d73. Consider uploading reports for the commit 2080d73 to get more accurate results

❗ Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.

@@           Coverage Diff           @@
##             main     #603   +/-   ##
=======================================
  Coverage   91.66%   91.66%           
=======================================
  Files           6        6           
  Lines        1944     1944           
=======================================
  Hits         1782     1782           
  Misses        162      162           

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

Update: I've sent an email to @segfault.

Can do

Done. Sorry for the lag. Missed the initial email notification.

No problem, and thank you!

Added to https://test.pypi.org/manage/project/ujson/settings/publishing/:

• Merge, check deploys to TestPyPI

After updating cibiuldwheel (#604), it successfully uploaded to TestPyPI via trusted publishing 🚀

• https://github.com/ultrajson/ultrajson/actions/runs/5893641388/job/15986074245
• https://test.pypi.org/project/ujson/5.8.1.dev11/#files

So I've also:

• Delete long-lived TEST_PYPI_PASSWORD from ultrajson/ultrajson/settings/secrets/actions
• Delete long-lived ujson-gha token from my account at test.pypi.org/manage/account

So we should all be set for whenever we next want a prod release.

@hugovk FYI building in the same job as uploading opens up a possibility for privilege escalation through build dependency poisoning, that's why it's recommended to build in a separate job. Besides, it would be useful to build the platform-specific wheels from sdist and not from a Git checkout.

What privilege would be higher than poisoning the wheels we build?

it would be useful to build the platform-specific wheels from sdist and not from a Git checkout

What makes you say that?

What privilege would be higher than poisoning the wheels we build?

GitHub's OIDC token can eventually let someone access services other, than PyPI. That's why, while working on the secretless publishing in my pypi-publish action during the private beta, we wanted explicitly ask that people separate the jobs. My PyPUG guide caught up with that recommendation a bit later: https://packaging.python.org/en/latest/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows/.

it would be useful to build the platform-specific wheels from sdist and not from a Git checkout

What makes you say that?

That's kinda tribal knowledge, partially. But essentially, that's what pip install does when installing from sdist.

If you don't build from sdist, you may end up shipping a tarball that doesn't contain all the necessary bits for building+install wheels from it. What's present in Git isn't necessarily a part of sdist.

Also, this helps make sdists usable by the downstreams. Distro packagers mostly use sdists from PyPI to repackage RPMs and similar, treating them as the buildable source.

cibuildwheel supports building from sdist natively, by the way, to support this specific use-case.

Additionally, I have a GitHub Action to support using sdists in CI instead of a Git checkout, to improve the downstream compatibility even more — https://github.com/marketplace/actions/checkout-python-sdist.