Digital attestations requirement blocking PyPi publishing

[jpl-jengelke]

The following error blocks PyPi from accepting release uploads:

Uploading distributions to https://upload.pypi.org/legacy/
ERROR InvalidDistribution: Upload with attestations requested, but
dist/exotic-4.2.3.zip has no associated attestations

It appears that the attestation file for the ZIP archive is not being created.

Solution 1:

   with:
     attestations: false

Solution 2:
Generate attestations for that file.

Probably solution (2) is preferable since it preserves PyPi PEP 740 supported publishing.

Why did this happen?
The attestations feature is now enabled by default, and PyPi Warehouse is now enforcing it.

[jpl-jengelke]

@rzellem @tamimfatahi This is why our release is not published on PyPi quite yet.

[jpl-jengelke]

This is our action workflow file for publishing.

[webknjaz]

You could also split your dists and upload via separate action invocations.

[woodruffw]

Looking into this now -- it's strange that both dists appear to be present, but only the .whl gets attested: https://github.com/rzellem/EXOTIC/actions/runs/11689855918/job/32578984845

I'll continue to root-cause this.

[woodruffw]

Figured it out: the current attestation helper in this action collects distributions like so:

https://github.com/pypa/gh-action-pypi-publish/blob/a8b73a6d88e1c2ae7ee7bf90b8ebba800a10f203/attestations.py#L54-L68

Notably, it collects *.tar.gz but not *.zip, since I didn't realize that the other was even still allowed as an sdist extension. I'll confirm and send a fix PR in a moment.

[di]

PyPI doesn't fully support PEP 625 yet: pypi/warehouse#12245

warehouse=> SELECT DATE_TRUNC('month', upload_time) AS month, COUNT(filename)
FROM release_files
WHERE packagetype = 'sdist'
    AND filename ILIKE '%-%-%.zip'
    AND upload_time >= DATE_TRUNC('month', CURRENT_DATE) - INTERVAL '30 months'
GROUP BY DATE_TRUNC('month', upload_time)
ORDER BY month DESC;
        month        | count
---------------------+-------
 2024-10-01 00:00:00 |    12
 2024-09-01 00:00:00 |    13
 2024-08-01 00:00:00 |     6
 2024-07-01 00:00:00 |    10
 2024-06-01 00:00:00 |    25
 2024-05-01 00:00:00 |    19
 2024-04-01 00:00:00 |    64
 2024-03-01 00:00:00 |   138
 2024-02-01 00:00:00 |    46
 2024-01-01 00:00:00 |    26
 2023-12-01 00:00:00 |    56
 2023-11-01 00:00:00 |    64
 2023-10-01 00:00:00 |    74
 2023-09-01 00:00:00 |    44
 2023-08-01 00:00:00 |    79
 2023-07-01 00:00:00 |    95
 2023-06-01 00:00:00 |   104
 2023-05-01 00:00:00 |   138
 2023-04-01 00:00:00 |   120
 2023-03-01 00:00:00 |   142
 2023-02-01 00:00:00 |   118
 2023-01-01 00:00:00 |   103
 2022-12-01 00:00:00 |   122
 2022-11-01 00:00:00 |   165
 2022-10-01 00:00:00 |   130
 2022-09-01 00:00:00 |    83
 2022-08-01 00:00:00 |    98
 2022-07-01 00:00:00 |    56
 2022-06-01 00:00:00 |    71
 2022-05-01 00:00:00 |    94
(30 rows)

[di]

@jpl-jengelke Somewhat unrelated, but I'm curious why are you choosing to publish a .zip here in the first place? Note that once PEP 625 is accepted, .zip will no longer be a valid format for a source distribution.

[jpl-jengelke]

@di @woodruffw

@jpl-jengelke Somewhat unrelated, but I'm curious why are you choosing to publish a .zip here in the first place? Note that once PEP 625 is accepted, .zip will no longer be a valid format for a source distribution.

Good question -- Explained here. In a cross-platform product geared to a broad target audience that may include beginning users, it behooves us to be extremely user friendly.

[webknjaz]

That doesn't really demonstrate any real limitations, though...

[jpl-jengelke]

Yay! This is working... Thanks everyone for all the efforts!

[jpl-jengelke]

That doesn't really demonstrate any real limitations, though...

I understand the sentiment. But this was a PEP that did not need to be done IMHO. (It changes the long-standing precedent of the PEP 517 spec on Source Distribution to be non-backward compatible and generally makes something harder to do.) Imagine a user base of non-developers, perhaps even those who rarely use Windows machines but have to use them to run certain software. No matter what, it's an extra step just to peer at the packed source. Now imagine the docs on how to install and run the application are also packed there in a single location.

[webknjaz]

As I said in the linked issue — having Python means having means to untar. Plus, the end-users should really install from wheels which are zip archives, not build from source, if you care about simplicity.