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

Ben Pfaff blp at ovn.org
Tue Nov 22 05:42:46 UTC 2016


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.


More information about the dev mailing list