0.22.0: No tests in sdist tarball

[dvzrv]

Hi! I'm packaging this project for Arch Linux. When packaging 0.22.0 I noticed that there are not tests in the sdist tarball on pypi.org.

Since downstream distributions tend to use these tarballs in their build systems (and some do run tests! :wink: ), it would be awesome if they could be included! :)

[sirosen]

That sounds very reasonable to me! I'm not in the habit of including tests in my packages because most aren't being repackaged.

I'll get to work on this when I can circle back to work more on check-jsonschema -- hopefully this week.

[sirosen]

I just gave this a quick try and it's going to take me a bit longer than I hoped to get this done, so it won't be in the next release.

Several tests refer back to the pre-commit data (.pre-commit-hooks.yaml), so I'll need to remember / figure out how to graft that data into the sdist to make the tests runnable.

[dvzrv]

Meanwhile we have started to discourage the use of PyPI sdist tarballs (for various reasons) for distribution packaging on Arch Linux.

Feel free to close this issue (I will be using auto-generated tarballs from github for the time being, until they break those as well next year :rofl: ).

[sirosen]

This had fallen off my radar, so this update is a good bump/nudge for me. I'd still like to distribute the tests along with the builds, so I'm going to keep this open until I do it.

As you said in the linked thread

Upstreams quite often do not care about sdists being testable...

I didn't care (for this project), but now somebody has told me that it would help them, so I do care!

So give me another chance to right this, at least in this one little package in one little corner of the world. :slightly_smiling_face:

---

Let me know if there's any other way that I can help accommodate this. e.g. I could attach builds to the GitHub Releases. I'm not sure I can do much to address the security/integrity angle of things. From the thread, you also wrote

The source tarballs are created by an arbitrary process, governed by varying rules, on someone's machine or in some pipeline

Even if I wire up GitHub Actions here to publish as a release artifact, there's no way to guarantee stability from that. Repo admins can manually substitute out an artifact for something they built on a local box, and I don't think GitHub offers any kind of public audit trail for that activity.

I'm not sure what kind of publishing flow would give you what you need. If publishing an sdist, wheel, and hashes of those artifacts, to GitHub Releases would be useful, I'm happy to do it though!

It also might be useful context to be able to bring to the Python Discourse, when I have the energy to engage there (the packaging threads are long and seem to sap everyone's strength and goodwill).

[dvzrv]

Even if I wire up GitHub Actions here to publish as a release artifact, there's no way to guarantee stability from that.

To my knowledge attaching to releases on github would at least ensure that the artifacts remain unchanged. The auto-generated tarballs will likely change next year (and break thousands of packages in the process).

I don't particularly care for sdist tarballs (any source tarball would do), especially as sdist tarballs are sort of undefined.

[sirosen]

I don't have a totally firm grasp of what would be ideal, but I already have a workflow which drives releases to pypi off of GitHub releases. It's pretty trivial for me to add a step at the end which attaches the just-published builds to the release.

The sdist is well defined; it's whatever the current version of setuptools puts in there based on how it's invoked and whether or not Mercury is retrograde! What could be simpler! 😝

[sirosen]

Okay, starting in v0.26.2 (just released), I have the sdist and wheel available as release artifacts.

I don't plan to backport this to old releases, but I think the last lingering thread here is wrapped up for now.