[Python-Dev] Overriding stdlib http package

[Brett Cannon]

On Wed Jan 14 2015 at 4:08:52 PM Demian Brecht <demianbrecht at gmail.com>
wrote:

> 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
> fork
> > easily) and do your work there? Even with commit privileges you wouldn't
> be
> > 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
> produced.
>
> 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 [1]
> > Commit changes to httlib3
> > Generate patch for CPython
> > Import patch to local CPython
> > Run unit tests [1]
> > Generate hg patch (patchA) for submission to bug tracker
> > Upload patchA
> > patchA is reviewed
> > Implement review changes and generate patchB [1]
> > 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...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150114/9947611b/attachment.html>