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-poc Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack-poc More help : https://help.launchpad.net/ListHelp
