Can you share update on project status?
natemcmaster opened this issue · comments
Hi there, what is the status of this project?
I see the updates to this repo basically stopped in early 2017. Is the project permanently dead/dormant/just taking a break? I know ipaddress was added to the Python 3 stdlib in 2012 and has much of the same functionality, and wouldn't be surprised if you had decided to focus your time on other things. If so, it would be nice to know if you are not planning to work on this anymore so the community can focus on porting to ipaddress.
Also, one minor thing...I can't use this library in anything > Python 3.6 due to a small bug. I see #167 was merged to fix it, but it hasn't been published to pypi.org. Any chance you're planning to push this out? Python 3.7 was released almost 2 years ago and I'd like to upgrade to keep up with the latest Python releases.
Many thanks! I know from my own experience that maintaining open-source can be a thankless job. I really appreciate your effort and thank you for sharing your code with the world :)
@snordhausen I do not want to be rude but do we really have to fork and release a netaddr project to give it another life?
I know at least few packages that still rely on netaddr: oslo.config oslo.utils which directly affect subunit2sql.
I really do not want to see runtime warnings even from code that does not even load that library! ...hint py38 does.
.pyenv/versions/3.8.2/lib/python3.8/site-packages/netaddr/strategy/__init__.py:189: SyntaxWarning: "is not" with a literal. Did you mean "!="?
Note: yes, I would not mind spending few hours fixing urgent issues/prs.
@drkjam I see you own the pypi package. Any idea what we can do to revive the project?
@ssbarnea @natemcmaster and netaddr users,
It is evident that there has been little to no active development on this project in several years.
My work and personal life keeps me away from spending time actively developing open source software these days. I won't speak for @snordhausen but, like myself, is likely similarly busy with other concerns.
Since Python 3.x has now become the de facto version to use and there is now an adequate standard library ipaddress module available (with an associated PEP), it would make sense to switch to that for your needs going forward where possible.
If there are any gaps in functionality I suggest submitting those requests to the Python core dev team for consideration and inclusion in future versions of the standard library rather than in this project.
As there are still a substantial set of users who rely on this project I do feel a responsibility for all existing releases and the quality of any future releases put out by this project.
If there is serious interest from individuals willing to take on the work and responsibility of becoming maintainers, we would consider those and at some point in the future be convinced to hand over access for PyPI releases.
The current netaddr team would play an active role in ensuring a smooth and stable transition to new ownership if this ended up as a viable path.
I am not against others forking this project - it is your prerogative to do so. The only issue will be with taking over the netaddr namespace on PyPI or ownership of this project on github. Setting up a netaddr2 or similar is perfectly fine and you can develop and build a user base around that if you wish.
If anyone has comments, suggestions or is interested in becoming a maintainer (serious offers only please) reply here or send myself and @snordhausen a personal email and we'll see what we can do.
Many thanks for your interest and support over the years.
@drkjam Thanks for the quick update on this. As I am looking more on the practical side (what can I fix today), I ended up forking the library to https://github.com/pycontribs/netaddr/ and publishing as https://pypi.org/project/netaddr2/ -- That is a maintenance fork aimed only to provide bug fixes until we can sort-out the future.
I anyone needs a hotfix, feel free to file it there and I will make a quick release for it. As you said netaddr is in its late-life but this should no be a reason for breaking consumers that did not drop it yet.
Note: A well desined CI/CD procress could enable publishing to pypa on a new release tag, avoiding the need to update PyPI ACL.
@drkjam thank you for the reply!
It's understandable that this project would move into a maintenance-only or sunset mode. I wasn't asking for you or anyone to dedicate more time to this. I was just hoping to know if you had definitive plans for either depreciation or resuming active development.
As my use case is covered by the functionality offered in ipaddress, I plan to port my code to use that dependency now.
Thank you for producing the original version of this library. Prior to ipaddress, this library was essential for some of my school work and later, professional work. I appreciate your willingness to contribute to open source!
Thanks for this @ssbarnea et al. It'd be great to add to the README of this project both the existence of netaddr2, as well as a pointer to stdlib's ipaddress for new projects.
One comment I'd like to add is that there is nothing in stdlib to handle layer 2/EUI/MAC addresses, i.e. what netaddr.eui provides. To my knowledge, there is also no other package in PyPI for that piece of functionality either.
As netaddr is winding down, it'd be great if that functionality still existed in either as a simple cleaned-up PyPI package, or even submitted to stdlib for inclusion. Thanks to eveyone involved for all of your efforts!
I have to say that more and more often I encounter these annoying warnings related py38, and netaddr is used by Ansible and I have no way to address this issue, especially as ansible itself supports a huge range of python versions.
It would really be preferable to fix this warning and make a new release, and avoid forking (or even vendoring).
Hi, I'm part of the Community Team at Ansible.
What can we do to support you in allowing another release to happen? Is there any specific testing we can do? I wonder if that would work well as a short term fix?
@paravoid Is it far for me to say based on your comments in #202 (comment) that we need to start the discussion with Python Core Team to see if they would be interesting in allowing functionality be added to ipaddress?
TBH, I think that nothing done to python core can help Ansible, mainly because Ansible runs on python codebases that are fast beyond they EOL, like py26-py27.
The only reasonable move here seems to be patching netattdr to addresses these syntax warnings. If the current maintainer does not have the time to do it, they should show good will and allow someone else to continue the maintenance burden.
I did not investigate it very deeply by I believe that netaddr may be an indirect dependency that gets slipped in from multiple packages. In that case forking it does not help it at all, the rotten one will be dragged in by another dependency.
I am aware about few extreme cases where community requested taking over unmaintained namespaces in order to be able to patch a library where the original owner disappeared, unwilling or unable to do anything. I hope we would not have to go this route.
In the end, if we look back that syntax errors are such a trivial fix.
I have a lot of respect for those that are able to handle stuff to next generations when they realize they can no longer continue maintaining a project.
Well, Ansible could also try to not use netaddr on more modern Python versions and only load the library on older ones. I don't know which parts are used where of course, but conditional imports are a thing.
@MarkusTeufelberger I am not sure what Ansible could or couldn't but one thing for sure: if someone is importing netaddr from their own module, we will still see this happening. If I remember, well that warning will become an error on py39.
It happened that I encountered this with Ansible, but I am sure that there are other consumers of netaddr around. If it was only Ansible, probably they could have vendored it.
In fact in devel branch they removed most (not all) use of netadd. That was partially due to removal of modules from core. As you can image, nobody will be able to backport changes stable branches, mostly because replacing netaddr with something else would not count as a bug fix from their POI.
The more interesting bit is that Ansible itself does not list netaddr as a directly dependency and asks user to install it to enable some funcitonality (modules/filters) that uses it. Basically it is a weak dependency so they outsource the blame to netaddr. So basically we are moving nowhere because everyone claims "not my problem".
@paravoid Is it far for me to say based on your comments in #202 (comment) that we need to start the discussion with Python Core Team to see if they would be interesting in allowing functionality be added to
ipaddress?
I don't think EUI/MAC would fit to ipaddress per se, but a new module could be created to cover this use case specifically. You could start that discussion/make that feature request, but I suspect you may have better success if you were to create a module on PyPI first, that is clean, focused (EUI/MAC-only) and interoperable with the ipaddress module. The Python devguide actually covers the topic of "adding to stdlib". I'm neither a netaddr maintainer, nor a Python core developer though, so take my comments with a grain of salt :)
Well, seems so far we're stuck at what @ssbarnea feared might happen: "not my issue"-problem.
We still have no solution to go with. I'd favour a change of dev/maint of this netaddr pkg as for the reasons already stated above.
Please someone merge the fix already introduced with the fork netaddr2 and be done with it for the time being.
Thank you.
Hey all, as an update on this matter: I just started helping with netaddr maintenance and producing a new release addressing the most pressing concerns (SyntaxWarnings, shebang mismatches, supporting PyOxidizer by avoiding __file__ use), expect a new version soon. After that's done I'll try to go through all the remaining pull requests and issues and address them as the time permits.
That is clearly very good news! Let is age slowly instead of putting it down by not updating it.
Version 0.7.20 has just been released, so, seeing that the most important issues are addressed I'll close this issue. Thanks all for your patience.
@jstasiak thanks for the update!!
This is great news. Thank you for your help :)
I would like the say a big thank you to @jstasiak for offering his time and energy in getting this project back on track. It means a lot to me personally and has taken a huge weight of responsibility off my shoulders.
Thanks also to others who offered to help out as well and for all the users who have raised issues and submitted MRs and bug fixes over the last several years. My apologies for not being more on top of things.
Looks like netaddr has a life after my active involvement since it started (way back in 2008!), which is a great feeling. Here's to continued improvements and a greater involvement from the netaddr user base!