Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HELP: looking for new maintainers #139

Open
saghul opened this issue Feb 10, 2021 · 8 comments
Open

HELP: looking for new maintainers #139

saghul opened this issue Feb 10, 2021 · 8 comments

Comments

@saghul
Copy link
Owner

saghul commented Feb 10, 2021

TLDR: I can no longer maintain this project to the degree it needs to be maintained and I'm looking for a new maintainer(s). If you'd like to step up or propose a way forward (someone mentioned the aio-libs org) please leave a comment. ❤️


I started this project almost 10 years ago, in my quest to improve my C skills and learn more about Python internals. In this process I also learned about how c-ares works and many more things. It started with the Python C API, and then, thanks to multiple contributions we transitioned to cffi. Then came wheels.

Python is and has always been my favorite programing language, but I no longer use it on a daily basis and my day got more complicated so I no longer have the time to pour some love into this project. I never had a use case for this package, I just did it for the sake of learning. Python being my favorite language, I loved to come back to fix the occasional bug, but that is no longer working.

I've come to realize there is a grieving process here. It starts with denial: "I'll find some time next month for sure!" and ends with acceptance, ie, this piece of text right here.

This project has helped me become a better developer and to collaborate with many great people throughout the years. It was really humbling to find out that aiohttp started depending on it, and that's probably how it reacched 750k downloads per month.

It's not time to pass the torch and put this project in new, loving hands. Are you that person? Please leave a comment.

@hynek
Copy link

hynek commented Feb 11, 2021

The real source btw: https://pepy.tech/project/pycares :) Since aiodns is very close, you're probably right: https://pepy.tech/project/aiodns

@kigawas
Copy link
Contributor

kigawas commented Feb 22, 2021

c-ares is evolving quickly, but this project is still using an ancient c-ares version, which causes lots of build problems with Python 3.9 on Ubuntu 20.04 and macOS 11 due to:

Upstream c-ares is not willing to apply a patch adding TTL support. I did apply the patch to the bundled c-ares, but unfortunately it breaks the ABI, so attempting to use a system provided c-ares is not possible.

In my opinion, c-ares has some TTL support differently now. I'm not a DNS expert, but it's really doubted that many would need "TTL in SOA, TXT, SRV and MX". If they do, it should have been integrated into c-ares long time ago.

If you really want to cease maintaining, I suggest two options:

  1. Drop the pycares dependencies for aiodns and use ffi directly with c-ares in aiodns (requiring some work and perhaps a new library superseding this)
  2. Upgrade the c-ares code and apply your patch to fix build errors on latest *nix OSs (requiring less work)

For long term development, 1 is better. If we want to get things fixed ASAP, 2 is also a good start.

@boytm
Copy link
Contributor

boytm commented Feb 23, 2021

I can try to be one the maintainers,but English is not my native language.

And about new platform, I think we should directly drive script "configure" to generatre the config.h.

@webknjaz
Copy link

webknjaz commented Apr 9, 2021

Sounds like this lib and aiodns are indeed perfect candidates for @jazzband (cc @jezdez). It's dramatically easier to maintain things collectively + this ensures there are fewer single points of failure if somebody wants to step down from contributing regularly.

One thing that would be helpful for the new maintainers is some docs around what is the canonical package build workflow and test runtime considerations. If that's missing, I envision it to be hard for somebody new to figure out the processes — having the need to do Git archeology substantially increases the entry level for the potential future maintainers.

@HassanAbouelela
Copy link
Contributor

Not sure if much is still happening here, but I needed a 3.9 wheel, so I just went ahead and made it on my fork and PRed it. Some work is still needed to publish it to pypi, but I've done most of the grunt work in bumping versions, updating CI, and documentation. I've tested the package a little bit in my own projects, and nothing seems to be out of the ordinary.

Pypi currently lists just @saghul as the only maintainer, I hope they have a chance to look at my PR soon so we can get the ball rolling again.

@saghul
Copy link
Owner Author

saghul commented May 9, 2021

Will do, thanks a lot for picking this up!

@saghul saghul pinned this issue May 11, 2021
@saghul
Copy link
Owner Author

saghul commented May 11, 2021

Update: thanks to the work by @HassanAbouelela and some other PRs we are in a better shape now. I managed to find some time to work on automating everything, and now releases to PyPI are fully automated when making a GH release, including building wheels for all platforms (aarch64 is on PR).

3.2.0 is now out for Python 3.5-3.9 and wheels for all platforms.

EDIT: 3.2.3 is out with aarch64 wheels included.

@saghul
Copy link
Owner Author

saghul commented May 13, 2021

Update 2: got excited with all the automation and made a 4.0 release. c-ares is now pulled in as a submodule. No custom patches. Linking with the system c-ares is now possible too.

With these improvements and the release automation it should be much easier for anyone to come and help maintain this forward!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants