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ć
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53b3dbc7.5020...@pke.hr
