Support for Python versions >=3.9

[asdrolias]

On ticket #2404 it was mentioned that there are thoughts to start dropping support for EoL Python versions.
However, is the a plan to support Python 3.9/3.10/3.11 versions?

[wbarnha]

I'm a bit confused. kafka-python in master does support the aforementioned Python versions, up to 3.12. If you're talking about the badge displaying support up to 3.8, it's because the latest update has not yet been released to PyPi yet. I apologize for the delay, I'm trying to reach the maintainer to get a release put out.

[palunel]

Also keen to know when this update will be available on PyPi

[wbarnha]

Just reached out to Dana for PyPi permissions. If there's no response, I'm going to apply for PEP 541 in https://github.com/pypi/support/projects/1 to claim control over the project.

[vsel]

@wbarnha Have you tried to contact him on Twitter? https://twitter.com/dana_powers

[wbarnha]

I did not know he had a Twitter, thank you for pointing that out to me. However, it seems that he has been inactivate there as well. I've used email in the past to reach him and that's how I got push access.

[wrenmck]

Good day, has there been any progress on this issue?

[wbarnha]

Still haven't heard back from him yet. The other maintainer and I have agreed to take further action on December 8th if we don't hear back.

[Romain-Geissler-1A]

I don't want to sound too negative, but what I see from the different PEP 541 requests is that the list of request grows and pypi folks struggle to manage them since months/years. Many request either end up either as resolved (if the original owner is eventually reachable, which is great), either people end up renaming their package (which admittedly is not a great "solution").

[wbarnha]

I agree, hence why we're going to have to keep reaching out to him.

[wbarnha]

Dana got back to me, hold your horses folks. We're working on it.

[asdrolias]

Thanks @wbarnha for getting back on this. Is there an approximate date that you can share? Jan 2024 Feb?

[wbarnha]

I'll need to follow up with him again. PyPi credentials are currently being sorted out.

[mro-rhansen2]

Dana got back to me, hold your horses folks. We're working on it.

Is there any update that you can provide at this time?

[wbarnha]

Dana got back to me, hold your horses folks. We're working on it.

Is there any update that you can provide at this time?

Haven't heard back at all, I followed up last night, coincidentally. Believe me when I say I'm quite eager to get the next release out. 😔

[Romain-Geissler-1A]

Hi,

Any news from the historical maintainer ?

Thanks for all the work trying to revive/take over this repo ! ;)

[wbarnha]

Hey, still keeping in contact. Long story short, our personal lives are a bit busy at the moment so hopefully we'll be back in running order soon.

[ubernostrum]

I am not trying to be unkind here, but getting a new release published should not take four months of back-and-forth, and if the person who volunteered to do it is now falling into the same "no time to" problem as the original maintainer, I think that person probably should not be trusted to maintain the package going forward, either.

So I will make an offer.

I am willing to help put in the work to publish a Python 3.12-compatible version of this package and then to formally hand it over, for long-term stability, to a collaborative maintenance group such as Jazzband, if whoever has the necessary access would be willing to grant me permission to do so, which would require both full commit and admin access to this repository on GitHub and full access to this project on PyPI.

However, this is a one-time, time-sensitive offer. Like you, I am also a busy person, and while I am willing to spend my time and effort on helping this package, I am not willing to spend months or years of my time and effort on sending endless messages offering to help and getting absolutely nowhere. So @wbarnha @dpkp this offer stands for one week and I will do zero followups.

Being familiar with GitHub and PyPI, I believe the total amount of time which will need to be spent to grant the necessary permissions is about five minutes. If you are willing to spend that amount of time, great. If not, that's unfortunate and I guess I'll have to look at other options.

[wbarnha]

Thank you for your feedback. You are welcome to create a fork if necessary, however, I do not have 1) admin permissions and 2) PyPi access. The only person who has PyPi access is @dpkp.

Please understand, I was on vacation and I just got back. I understand your frustration, I have been trying to get a release out for some time. If I had proper access, then we would not be having these issues.

if the person who volunteered to do it is now falling into the same "no time to" problem as the original maintainer, I think that person probably should not be trusted to maintain the package going forward, either.

I'm willing to help put forward bugfixes and merge improvements. I have triaged many existing PRs and merged changes in to be as minimally-invasive possible while fulfilling the requests of @dpkp to retain compatibility in certain areas for the next release (v2.0.4). I ramped down my contributions to open source software because I wanted to take care of some affairs in my personal life. Please understand that I do not intend to block the development of this project. I am merely powerless until proper credentials are granted.

[ubernostrum]

Have you recently been in touch with @dpkp?

Have they said anything about being willing to grant permission to publish a package, or ideally to transfer control to people with more willingness to maintain?

I am sympathetic to people being busy and having lives, since I am busy and have a life. But the impression I get from reading this thread is that they are too busy to release a package and also refuse to let anyone else do it, and that is something I am not sympathetic to, because it is disrespectful to the people offering their time and effort.

Can you outline what the actual, specific status is and what the remaining obstacles are to someone being able to actually publish a package?

[wbarnha]

Still haven't heard anything, we've been reaching out periodically over the past few days.

[ascopes]

At this point, it feels like just forking and uploading under a new name to pypi would be simpler. The advice can then be to migrate to that version from here.

Reason I suggest that is right now: this library not being compatible with 3.12 hinders the ability to update any other software that needs to move to Python 3.12. This can mean that users have to find an alternative to keep within policies for their organisations.

Additionally, if any security issue is found in this project or its dependencies, it is a production risk for them.

Fully aware everyone has their own lives to deal with, but since you (@wbarnha) are putting a lot of work into this project anyway to keep it up to date, I think it would be worth considering so that the community is able to benefit from that hard work!

[wbarnha]

I agree, I'll fork and release later today.

[wbarnha]

Fork is now underway at https://github.com/wbarnha/kafka-python-ng/

[wbarnha]

Just a note: All previous Python versions below 3.12 work with Kafka 0.8.2.2, but for some reason 3.12+ are incompatible. I'll note this in documentation, somewhere, when I get the chance.

[wbarnha]

Hello everyone, kafka-python-ng==2.0.3 is now available!

pip3 install kafka-python-ng

[Romain-Geissler-1A]

Ah so there is fork under a new name in the end, I wish somehow the original author could have taken 5 minutes to just grant you the pypi access if this was the only blocking point. Anyway, let's move on it's good news that there is now a release installable the normal way, thanks for that.

So now what's the plan for this repo. There are issues and pull requests, most people won't find out this issue and won't know about the new fork. So is there any plan to kind of "copy/migrate" existing issues/pull request to the new repo ? And is there a way to communicate this change of package name ? Even if the pypi process will take ages, would it make sense to initiate the pypi process to re-gain access on the original package, so eventually in 6 months or so you can change the pypi description of the old project to redirect to the new project ? Or maybe even publish a new "fake" release in the old project automating this process (I know with rpm/deb this is possible, don't know if this is possible with the python package manager) ?

[wbarnha]

Ah so there is fork under a new name in the end, I wish somehow the original author could have taken 5 minutes to just grant you the pypi access if this was the only blocking point. Anyway, let's move on it's good news that there is now a release installable the normal way, thanks for that.

So now what's the plan for this repo. There are issues and pull requests, most people won't find out this issue and won't know about the new fork. So is there any plan to kind of "copy/migrate" existing issues/pull request to the new repo ? And is there a way to communicate this change of package name ? Even if the pypi process will take ages, would it make sense to initiate the pypi process to re-gain access on the original package, so eventually in 6 months or so you can change the pypi description of the old project to redirect to the new project ? Or maybe even publish a new "fake" release in the old project automating this process (I know with rpm/deb this is possible, don't know if this is possible with the python package manager) ?

To be honest, I had external pressures on me preventing me from forking. I was originally going to invoke PEP 541 to begin the transfer process, but internal discussions led us away from that concept. However, given the lack of responsiveness for the past few months, especially considering how assertive I've been, I've decided to deal with the consequences and make an executive decision to fork. I'm very cautious about messing with the releases setup for kafka-python, because if I did, I'd need to clean up the releases, and for such a widely used project, I would like to be very careful about this. Obviously I plan on being more verbose about the fork tomorrow when I have more time to draft notes.

Regarding the plan for this project, I've been meaning to write a bot for some time that can copy existing PRs and Issues into new projects. If a human can do it manually, surely a bot can as well? (Famous last words 😅).

I wish somehow the original author could have taken 5 minutes to just grant you the pypi access if this was the only blocking point.

🥲

Or maybe even publish a new "fake" release in the old project automating this process (I know with rpm/deb this is possible, don't know if this is possible with the python package manager) ?

I'm hesitant to interact with any package managers outside of the PyPi ecosystem using a fork for now. The fork is supposed to be a temporary (🥲) solution until access is properly transferred.

[dpkp]

project source supports python >= 3.9. closing issue.