[Python-Dev] Overriding stdlib http package
brett at python.org
Wed Jan 14 22:19:07 CET 2015
On Wed Jan 14 2015 at 4:08:52 PM Demian Brecht <demianbrecht at gmail.com>
> On 2015-01-14 12:25 PM, Guido van Rossum wrote:
> > I'm not sure how commit privileges would help you -- can't you just fork
> > the CPython (I'm sure there's already a Bitbucket mirror that you can
> > easily) and do your work there? Even with commit privileges you wouldn't
> > committing partial work unreviewed.
> The friendly module fork allows for others to easily (or at least the
> intention is to do it easily) use the module with the new, backwards
> compatible features as a drop in replacement for the stdlib module.
But as Guido pointed out, we _like_ it being difficult to do because we
don't want this kind of substitution happening as code ends up depending on
bugs and quirks that you may fix.
> Giving others the ability to do this would lend itself to the adoption
> of the module and bug reports and such before upstream patches are
> That said, the main downside to the friendly fork is the patch
> submission process: After changes have been merged to the fork, there's
> bound to be churn during the upstream patch submission, which would
> likely lead to something that looks like:
> > Implement feature/bug fix 
> > Commit changes to httlib3
> > Generate patch for CPython
> > Import patch to local CPython
> > Run unit tests 
> > Generate hg patch (patchA) for submission to bug tracker
> > Upload patchA
> > patchA is reviewed
> > Implement review changes and generate patchB 
> > Upload patchB
> > [...wait for merge...]
> > Merge delta of patchB and patchA to httplib3
> > Test/upload new PyPI package
> I see commit privileges helping in two ways:
> 1. I've experienced lag on a few occasions between review and merge. I'm
> assuming that this is largely due to a lack of dotted line maintainer of
> the http package (although I believe that the general consensus is that
> Senthil is the de facto maintainer of the package). Commit privileges
> would help in getting the patches merged once reviews are complete.
> 2. It would help my own workflow. While feature development can be done
> in httplib3, I do also tend to swap between issues in the bug tracker
> and large feature work. Because I have two lines of work (CPython/bug
> tracker and Github), I run into issues around where these changes should
> be made: Should the bug fixes live in CPython/bug tracker or should I
> fix the issue in httplib3 and go through the submission workflow above?
> Either way, I'm signing myself up for a good deal of headache managing
> the httplib3 work, especially when development work across feature
> branches is dependent on patches submitted to CPython.
> I definitely don't mind the extra work if there are no other options,
> but my end goal is to be a maintainer of the http package and core
> developer, not to maintain a third party fork.
How many other modules are dependent on the http module in the stdlib that
are going to be affected by your changes? One option is you fork http
**and** and modules in the stdlib that are dependent on it. You don't
really have to change the other modules beyond their import statement of
using http -- you can even do `import http3 as http` or something to
minimize the changes -- but you at least don't have to monkeypatch
sys.modules for others to gain from your http changes. Plus as you patch
stuff in http you may find you have/want to patch other dependent modules
as well and so you will have already done that.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev