Hi all.
Probably if suds-jurko or whatever is the unofficial “suds” that people should be using then there is a good chance that PyPI would be willing to transfer the name of suds to one of the forks. I’d have to talk to Richard to be sure about that but it’s potentially an option.That indeed would be really great. Jurko just had the same idea and it would be the cleanest solution. What steps should be done to achieve this? Is it enough to point Jurko to post a request on http://sourceforge.net/p/pypi/support-requests/ ?
As the original suds project really seems dead (I have not been able to make contact with the original author), and other people have suggested this before, I don't really see there being any external issues with taking over original project.
Here are my other related thoughts on the issue:* I have taken care to keep backward compatible with the original project as much as possible, including bumping up the version ids only upwards and taking care not to break Python 2.4 compatibility.
* I still have not taken over the original project's documentation and that is something I'd really like to do so I can update it with all the fixes/updates made to the library. If anyone has experience with epydocs and the toolchain used to generate the docs in the original suds project and is willing to assist, I can take a look at that this weekend.
* The fork is compatible with Python 2.4+ except for 3.0, and is actively tested on multiple versions, albeit only on Windows. Any suggestions on how I could 'plug it in' to some external test runner on debian would be much appreciated.
* If the suds-jurko fork is to be made public as a part of the debian distribution, I'd really like to rename it so it does not have my name in it. That was an ok identifier when the project was just 'my silly little fork', but now it just does not seem right.
* The name issue can be resolved by taking over the original project's name. However, I would really not like to do that before taking over the original project documentation.
* The only thing that pops to mind at the moment expect for bugs inherited from the original project are the two missing suds.client.Client methods (last_sent() & last_received()) Mathias already mentioned, but they are planned to be restored (and updated) anyway and this can be done fast, if required. I've been delaying this only because I'm using my time to design a proper test suite/environment for the project and would like to have tests for those function before reinstating them.
* Any technical issues you encounter - just let me know and I'm sure we can find a suitable fix/workaround. As the project is still in the formal status of 'my silly little fork', we can be very flexible with the project's structure & packaging. :-)
Hope this helps.
Best regards,
Jurko Gospodnetić