[ovs-dev] Proposal to move the Python lib to its own repo

[Ben Pfaff]

I'm worried that my response here effectively shut down the proposal.
That wasn't my goal; if it's valuable, let's do it, but I want more
information first.

On Mon, Nov 21, 2016 at 09:42:46PM -0800, Ben Pfaff wrote:
> On Tue, Nov 15, 2016 at 11:29:51AM -0600, Terry Wilson wrote:
> > The Python library isn't dependent on the code in the OVS tree. It
> > being in-tree has a few shortcomings. My rationale for recommending
> > the split:
> >
> > * Simple features and bugfixes for the Python lib can't be used by
> > other projects (like Neutron) until the very latest OVS release is
> > widely supported
> 
> I am not sure that I understand why.  Why would Neutron and other
> projects be more willing to use a pre-release version of an OVS Python
> library, than a pre-release version of OVS itself?  Or do you mean that
> the OVS Python library would release more frequently than OVS itself?
> 
> The following two bullets are related:
> 
> > * Python 3 support is only available in version 2.6.0+ even though the
> > code would work for previous releases
> > 
> > * Implying that the Python lib and OVS versions are related when they
> > aren't is confusing
> 
> The Python library and OVS version numbers are indeed related, in that a
> given version of OVS is meant to work with the same version of the
> Python library, and vice versa.  Maybe there is some flexibility in
> working with different versions, but if so then this is more by accident
> than design.
> 
> Scanning the recent commits to the repository, it appears that the main
> dependency is just that the main OVS code requires a new-enough version
> of the Python code.  Probably, this is not a big deal, but the split-off
> repos should explain the situation somewhere.
> 
> As you suggest, maybe the Python code from 2.6.x would work with earlier
> versions of OVS.  But this was not a foreseen use, so I would not want
> to recommend that users do this.  If we split the repos and start
> thinking about this kind of possibility, then I agree that similar
> combinations could make sense for OVS 2.7.x+.
> 
> > * A separate repo would allow adding committers that are familiar with
> > the Python code, but less familiar with the C code.
> 
> I'd rather have only "committers", not "OVS committers" and "OVS Python
> library committers".  We don't have "OVS committers" and "OVS Linux
> datapath committers" and "OVS Windows datapath committers" and "OVS-DPDK
> committers", for example.  We trust our committers not to commit code
> without obtaining assurance that the code makes sense, through careful
> coding and at least one quality review.  Part of that trust is trusting
> committers to recognize when their own understanding of a piece code is
> limited and therefore that they should obtain more or better reviews.
> In other words, I want to trust programmers who do not know C to commit
> to the C parts of OVS anyway, because they will take the trouble to get
> good advice.
> 
> > * As a Python-only project, it could be more easily tested, built, and
> > packaged according to Python project best practices.
> 
> I think that most of the Python tests run some part of OVS.  I'm not
> sure how effective the Python library tests can be if OVS isn't
> available.
> 
> > The current build process requires the Python code, but this is easily
> > remedied by using git submodules. People tend to reflexively dislike
> > them, but they are perfect for this application. The OVS tree can lock
> > to any particular commit for the new python-ovs repo and be guaranteed
> > that changes don't break the ovs build. I made a fork to show how
> > simple the change would be:
> > 
> > https://github.com/otherwiseguy/ovs/commit/6766131b42807829ea78dbc43d164db8926030e7
> > 
> > commit 6766131b42807829ea78dbc43d164db8926030e7
> > Author: Terry Wilson <twilson at redhat.com>
> > Date:   Mon Nov 14 16:03:43 2016 -0600
> > 
> >     Move python dir to a submodule
> 
> It's a straightforward change, yes, if it's valuable.
> 
> Documentation and webpage updates would be needed to explain the new
> build process.