15

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.

1
  • I thought it belonged here as it has a direct effect on the code of the project, be it just the 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? Commented May 8, 2013 at 11:41

1 Answer 1

8

Well, in practice when I fork a project and can't get – or don't want – my changes to be integrated in upstream, I rename the fork, in the README, I cite the original author but claim to be maintainer of that code source and link the source to my repository and in setup.py update the authors string to add my name after a comma:

name='renamedproject'
author='origauthor, me',
url='http://myfavoriterepository.com/me/renamedproject'

I have no sources to back me up, but that's the result of long discussions I had with other pythonista friends a while ago while drinking dark beers…

2
  • 3
    Well, if there's nothing more authoritative, then chatting with other pythonistas over dark beers will have to do ;) Commented May 8, 2013 at 14:03
  • Right so this is effectively what I've done, and then added an issue to the original project's github asking to get that project up on PyPI - if that happens I can simply remove the files from the original project and add it as a dependancy Commented May 9, 2013 at 9:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.