kombu: Kombu 4.2.2 PyPi package does not match GitHub release/tag changelog
It seems the kombu-4.2.2 package that was released (and found here https://pypi.org/project/kombu/#files) does not actually reflect the v4.2.2 tag/release on GitHub. It appears instead to be built from master.
$ unzip kombu-4.2.2-py2.py3-none-any.whl
Archive: kombu-4.2.2-py2.py3-none-any.whl
<snip>
$ head kombu/compression.py
"""Compression utilities."""
from __future__ import absolute_import, unicode_literals
from kombu.utils.encoding import ensure_bytes
import bz2
import zlib
_aliases = {}
_encoders = {}
Compare the above with compression.py on v4.2.2.
We found this by chance when running on a Python installation without bz2 available.
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Reactions: 7
- Comments: 18 (6 by maintainers)
Commits related to this issue
- Bump version: 3.2.2 → 4.2.2-post1 — committed to celery/kombu by thedrow 5 years ago
- Update dependencies This patch fixes an issue with a dependency that was removed from PyPI. More information is available here: https://github.com/celery/kombu/issues/966. — committed to anishathalye/gavel by jhollowe 5 years ago
- Fix missing version kombu=4.2.2 Version 4.2.2 was removed because a bad packaging issue https://github.com/celery/kombu/issues/966 — committed to erickgnavar/proma by erickgnavar 5 years ago
- Fix missing version kombu=4.2.2 Version 4.2.2 was removed because of a packaging issue https://github.com/celery/kombu/issues/966 — committed to erickgnavar/proma by erickgnavar 5 years ago
I released 4.2.2post1. Again, I apologize for the inconvenience.
Great!
@ntravis True, if something went really, really horribly wrong, the last resort of removing the release might be a way out. I’m just not sure if this case was serious enough (it’d be easy to recover from by upgrade of the dependency, it didn’t crash OS, it didn’t delete anything - just wasn’t exactly what it said on the tin) to warrant that. But that’s my personal opinion and I can see why other’s view might differ.
@thedrow Oh, well - mistakes will always happen, that’s only natural. What’s appreciated is the effort to remediate that - and kudos for that! 😃
I’d rather not have broken dependencies available as it will simply create more bug reports which we don’t have time to handle.
For whatever my opinion is worth, I think as long as pypi doesn’t offer a way to mark a release as “BAD”, removing that release is the least of evils.
I have no issues with how this was handled. Things happen. Thanks for your hard work ❤️
We had no issues with the missing dependency but when our auto scaler decided to add a new instance, the build failed because of the missing 4.2.2 version and took our whole (admittedly tiny and unstable) production environment down with it.
My personal opinion is that once you’ve released something, it should stay released. People end up relying on it sooner than you know and the bugs may not affect them. This breaks things that were actually working.
I’m only saying this to provide context. In the end it’s your decision and we’re all benefiting from your work for free, so thanks again.
Relevant to that comment, I will link this ticket to pypa/warehouse#345
I guess that there are no good answers here. I’ll do my best to avoid such mistakes in the future.
I guess 4.2.2 could have stayed there in PyPI, along with post1. We had it in dependencies (don’t know if it was actually being used, though) and stuff was working. Dropping the version made our build fail.
Got a bit stressed when I had to update it with poetry when it’s not a first-level dependency 😃 But
poetry lockkinda did it, though I’m not sure how different it’s topoetry update.@arlaneenalra from a few messages up above: “I’m going to yank the wheel and tarball and release a new one.”
https://github.com/celery/kombu/issues/966#issuecomment-450725054
and the justification: “It contained code which should not have been released and causes errors in production.”
https://github.com/celery/kombu/issues/974#issuecomment-450808002