Context:
I was looking to see if there was a tool to do something (in my case I was looking for a proxy that would allow for http log inspection from a python test framework).
There turned out to be a tool that would require only minor adjustment, and it seemed to be reasonably stable/mature, with no updates in the past 5 months (pymiproxy), so I forked the project (to here) and have got it working as I need. The goal behind the original project is simplicity, so I doubt a pull request would be accepted, especially since one of the files involved is only useful to my current employer.
Finally I thought I should update the setup.py
file, but I'm not sure - I have done a 'useful' amount of work on my fork, and while I have left the original files in tact, subclassing in my own modules, there is now significant additional functionality.
I don't know that I feel comfortable claiming to be the 'author' of this module as it would be installed by python, but as the fork project author, I also don't feel comfortable leaving support emails directed to the original project's author.
Question:
What is the general accepted best practice for forked projects? Should the project be renamed to indicate that it is of a different purpose? The original project is not available through pip or else the structure of my project would allow that instead of forking, I only wrap the original as a dependancy. Should I in fact roll back my changes, put these in a new project, and get the two both listed in pypl, or is doing this on behalf of the original author going too far?
Notes:
Headings added to aid speed-reading. I'm looking for accepted best practices, so please no opinions without sources to back them up, be it an authoritative blog post, or examples of other projects which have done the same.
setup.py
or if it involves splitting the project in two and making the third-party part more generally available - if there's a better guideline I'd be glad to hear it, but I always though code belonged here and process on programmers?