Large lag between Windows and Linux/OS X PyPI uploads about multidict

[asvetlov]

Fixed on master just now.
Forgot to apply the change before release.

[edmorley]

Thank you for the reply :-)

Unfortunately that won't fix the problem completely, since the manylinux wheels are still being uploaded some time after the sdist/windows wheels. As such, the pyup.io PR only includes a subset of the hashes (for people using --require-hashes), which will cause breakage once the remaining wheels are uploaded (since pip rightly prefers wheels to sdist).

The full fix here is to do the equivalent of:
aio-libs/aiohttp#2347 (comment)

[asvetlov]

I don't think we will change something in near future.
My intention was publishing tarball before any binary wheel, the challenge has solved.
If pyup bot doesn't regenerate hashes on adding new files -- it is the bot problem, not mine.
Upload is not atomic by definition, twine and other tools upload distributions one by one.
At this moment pyup bot might read incorrect (partial) info.
Moreover I can re-upload missing (by network problems for example) files next day or even later.

Sorry, I think current state is pretty fine, we cannot totally fix all your need but only reduce a chance of pyup failure by price of very hard work on our site. I doubt if it is required.

[edmorley]

If pyup bot doesn't regenerate hashes on adding new files -- it is the bot problem, not mine.

PyPI doesn't offer an API for detecting new uploads for a package afaict, only a feed of "first time a package has been seen". Therefore there is no way for pyup.io to work around this.

Upload is not atomic by definition, twine and other tools upload distributions one by one.

Agreed, though in that case there would only be a few minutes between each package. Here there are 3-12 hours between different wheels, which is much more problematic.

[edmorley]

Or to put it another way... even ignoring this issue, presumably it would be beneficial for this project if the general Travis end-to-end time was reduced. Reducing that time would also help this issue.

For example:

• Fixing the current use of Travis build stages, such that more things run in parallel
• Removing the Python "nightly" version for OS X, where the backlog is