+1
On Nov 7, 2011, at 10:53 AM, Monty Taylor <mord...@inaugust.com> wrote: > Dealing with the client libraries has become a little bit of a tricky > subject, which is both lacking consistency and direction - but is kind > of essential to the project. (a service without a client library isn't > nearly as useful) At UDS this past week, Joe Heck, Jim Blair and I sat > down for a while and worked through a bunch of the issues and would like > to propose the following: > > - Each project that exposes an API should have a separate client library > project. For instance, python-novaclient, python-glanceclient, etc. > > - Each of these projects will have its own top-level git repo and be > managed by gerrit just like a core project. > > - The python-*client project will be under the purvue of the PTL for the > main project (mainly so that we don't have an explosion of PTLs all of a > sudden) > > - Each client library project will release milestones and final releases > on the same schedule as the rest of the core projects. > > - The client libraries will release directly to PyPI at final release > time. If we do this, releasing the need to release main core projects to > PyPI is obviated (which is good, as we do not expect anyone to actually > install a running OpenStack from PyPI - but it is reasonable to expect > people to want to use client libraries from PyPI) > > - OpenStack projects that need to depend on these will reference the git > repo of the project in their tools/pip-requires file. This should take > care of depends for developers. Normal installation depends can be taken > care of by distro packagers as usual. > > As best we can tell, this should handle the development case and allow > for better pip installing of code into virtualenv for the developer > workflow without doing screwy things that imply deployment > infrastructure. Other solutions discussed involved multiple modules per > repo (which actually breaks pip -e) and creating our own PyPI that we > upload trunk eggs of all of OpenStack software from and then > reconfiguring install_venv.py to look at that repo. Those are both > kludgy, whereas this actually serves final distro needs as well as > developer needs. > > It also helps out with a versioning issue, which was that we were trying > to find a computer-workable approach for dealing with pre-release > versions of nova/glance/keystone that worked for both Ubuntu and for > PyPI - and it turns out that there isn't a good answer. With this > approach, the problem goes away. > > Finally, as we're on the cusp of rolling out some integration-test > gating of trunk, it's important that we can also gate all of the > components that are used as a part of that gating. (would suck if the > client lib being used to test broke all of a sudden) > > We'd love to get a PPB vote on this approach, and if people consent > begin to implement it. Glance needs to split its client lib out, and > keystone and nova client libs need to get moved to gerrit and the > openstack org. > > Thoughts or feedback? > > Monty > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openst...@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~openstack-poc Post to : openstack-poc@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-poc More help : https://help.launchpad.net/ListHelp
