Test.pypi.org is marginally unusable (if my explanation is correct)

Packaging
1

When I do pip install -i https://test.pypi.org/... package , it fails on dacite 1.8.0 . The same package exists in pypi.
I think that is because it uses only dependent packages from test.pypi when you install from test.pypi.
If that is really the case, I don’t see how it provides an educate simulation of the real scenario.
Am I right? Is there other explanation?

2

I think it depends on what you expect test.pypi to be. As far I’ve seen, it’s mostly used either as just a little sandbox, or a place to stage packages for a human to verify everything looks ok (the description rendered correctly, the right wheels are there, etc…)

I’ve used it to demo to people how to build+publish packages, knowing I’m not dirtying the real PyPI, since no one should be installing these things.

I suspect if you allowed pip to also pull from vanilla PyPI your installation would succeed.

3

Another thing the test PyPI has been useful for is validating
uploads, since twine check still doesn’t verify lots of the things
that could cause PyPI to reject an upload, e.g. invalid Trove
classifiers: Twine check fails to warn on invalid classifier · Issue #976 · pypa/twine · GitHub

1 Like
4

You can also try:

pip download --no-deps --index-url http://test.pypi.org 'dacite == 1.8.0'

to test if the package was actually uploaded. Any other tests aren’t much different from installing from a package on your local filesystem

1 Like
5

Ideally build backends would catch most errors that would invalidate upon upload. For example, Hatchling does error for invalid classifiers and I think others do as well.

1 Like
6

poetry check also validates metadata, such as Trove classifiers.

1 Like