Is pystun still being maintained?

jtriley / pystun

A Python STUN client for getting NAT type and external IP

https://github.com/jtriley/pystun

MIT License

435 stars 154 forks source link

Is pystun still being maintained? #10

Closed hoffmabc closed 9 years ago

hoffmabc commented 9 years ago

It seems like there isn't much activity here and we at the OpenBazaar project would like to enhance or improve some of the code here. We would much rather push these upstream if the project is still alive, but if not please let us know so we can seek out a different path.

Thanks!

jtriley commented 9 years ago

@hoffmabc The original project on google code wasn't on PyPI, development had stopped for years, and the original author gaohawk wasn't responding so I decided to adopt it, put it on github, and publish to PyPI. I'm not particularly an expert on STUN but I have maintained Python projects so I figured I'd try to give it a home and keep it relatively up to date. Besides that I plan to eventually use it in my StarCluster project to dynamically add/remove security group rules to restrict access to clusters on Amazon.

So the short answer is yes it's still maintained but gets very low traffic. I'd be more than happy to take enhancements/improvements but without proper tests it's hard to do that. I think a good first step is to write some tests for pystun and aim for 90% coverage before piling on new features/improvements. What do you think?

jtriley commented 9 years ago

@hoffmabc Would you be willing/able to write tests for pystun?

Renelvon commented 9 years ago

Hello @jtriley, I am from the OpenBazaar team. We recently had some issues with the STUN server list, so I decided to fork the project and maintain it. I plan to:

Install a Continuous Integration system (Travis CI).
Have the code statically analyzed via prospector.
Support Python versions 2.7+ for now, as well as 3.4+ in the future.
Split the I/O code from the response-processing code.
Unit test the response-processing code to verify it is following the RFC.
Showcase the test coverage via coveralls.
Follow good packaging practices and make the setup pip-friendly.

I 've already begun working on some of the above. Being backwards compatible isn't high on my list, as we mostly intend this to be an in-house project. However, I 'd be happy to work on a shared roadmap, so that our development can be pushed upstream, too.

jtriley commented 9 years ago

@Renelvon Cool! The changes you've made so far in your develop branch look good - mind submitting a PR for review? Moving forward it shouldn't be too terribly difficult to provide backwards compatibility at least for the public function/method calls and deprecate them over time - other than that I'm not opposed to major refactoring given that this is still very close to the original code and really needs it anyway.

Feel free to file another issue to review some ideas for a roadmap. Also, if you're interested in becoming the official maintainer of the project you should ping me on IRC (same nick on freenode)

jtriley commented 9 years ago

For the record: @Renelvon and I had a chat on IRC and agreed to eventually hand the project over to @Renelvon once the tests and coverage are in place. Until then I will continue to review and merge his PRs and handle making new releases. We've also agreed to keep the MIT license on the project moving forward.