----- Original Message -----
> On 04/10/2015 03:57 PM, Terry Wilson wrote:
> > This adds very basic support for setuptools so that the OVS Python
> > lib can be added to PyPI.
> 
> Most Python libraries are on PyPI, so it makes sense to put this one
> there, too.  Another specific reason this would be helpful is that in
> OpenStack, certain test enviornments are built as Python virtual
> environments, and the contents of those virtualenvs is Python packages
> installed from PyPI.  Not having this one there means we can't use this
> library in a set of the test jobs.
> 
> Ideally uploading to PyPI would become part of the ovs release process
> whenever a tarball is published.

Another thing to consider is that the Python library doesn't really depend on 
the Open vSwitch release cycle at all. It might make sense to actually move it 
to its own repo and do completely separate releases for it.
 
> If you don't want to do that but are willing to delegate it, someone
> else (like Terry) could take on the responsibility to do it after an ovs
> release is made.  It's not so different than a distro package maintainer
> updating their distro package of this lib.  In the case of PyPI, there's
> not really a distro, so it kind of makes sense to me for the upstream to
> "own" keeping it updated.

I'm ok with doing the PyPI stuff. After it is registered, as long as someone 
has their PyPI credentials set up, it should be as easy as just doing 'make 
pypi-upload' though.

> > This currently uses the Open vSwitch version number and the
> > generated dirs.py, though there is no real reason to tie the
> > Python libraries releases or version numbers to the main project's.
> 
> Changing it could cause unnecessary pain since the library is already
> packaged and installed via distro packages using the ovs version number,
> so I think it makes sense to do it the way you have it.

There is still a bit of bad interaction between packaged and non-packaged 
versions even without the version number stuff. The dirs.py file that would be 
generated during packaging processes would be different from the one that would 
be in PyPI. I guess that's the kind of thing you just end up having to deal 
with when you mix distro- and PyPI packaging, though. I couldn't really come up 
with an acceptable way to reconcile the issue of 'default paths'.

Terry

_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Reply via email to