Re: [openstack-dev] olso-config dev requirement
On 07/16/2013 11:42 AM, Doug Hellmann wrote: On Tue, Jul 16, 2013 at 7:58 AM, Mark McLoughlin mar...@redhat.com mailto:mar...@redhat.com wrote: On Mon, 2013-07-15 at 14:28 -0400, Doug Hellmann wrote: On Mon, Jul 15, 2013 at 11:03 AM, Monty Taylor mord...@inaugust.com mailto:mord...@inaugust.com wrote: I was looking in to dependency processing as part of some pbr change, which got me to look at the way we're doing oslo-config dev requirements again. To start, this email is not about causing us to change what we're doing, only possibly the mechanics of what we put in the requirements.txt file- or to get a more specific example of what we're solving so that I can make a test case for it and ensure we're handling it properly. Currently, we have this: -f http://tarballs..openstack.org/oslo.config/oslo.config-1.2.0a3.tar.gz#egg=oslo.config-1.2..0a3 http://tarballs.openstack.org/oslo.config/oslo.config-1.2.0a3.tar.gz#egg=oslo.config-1.2.0a3 oslo.config=1.2.0a3 As the way to specify to install - 1.2.0a3 of oslo.config. I believe this construct has grown in response to a sequence of issues, but it's complex and fragile, so I'd like to explore what's going on. The simplest answer would be simply to replace it with: http://tarballs.openstack.org/oslo.config/oslo.config-1.2.0a3.tar.gz which will quite happily cause pip to install the contents of that tarball. It does not declare a version, but it's not necessary to, because the tarball has only one version that it is. Is there a problem we have identified where the wrong thing is happening? I've tested that I get the right thing in a virtualenv if I make that change from pip installing a tarball, pip installing the requirements directly and python setup.py install. Is there anything I'm missing? Monty Without the version specifier, we are relying on all projects to install the right version from that tarball link when we run devstack, but we have no guarantee that they are moving to new releases in lockstep. Yep, that's it. The thing to test would be if some projects have the 1.2.0a2 tarball link and an one has the 1.2.0a3 link because it depends on an API that's new in 1.2.0a3. It's worse than that. What gets installed will depend on the order devstack installs the projects and what their respective requirements lists say. It is possible to end up with compatible source code installed, but with a version number that setuptools thinks is not compatible based on projects' requirements. In that case, setuptools may not let us load plugins, so services will start but not actually work. Thank you. This is what I needed here. BTW - I put this up: https://review.openstack.org/#/c/35705/ To take a stab at installing our global requirements list first, and then installing our projects in that environment. I also just made: https://review.openstack.org/#/c/37295/ Which would add oslo.config and oslo.messaging as git repos to the devstack system, so that we can track trunk like we do with the other projects. Monty ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] olso-config dev requirement
On Tue, 2013-07-16 at 13:37 -0400, Monty Taylor wrote: On 07/16/2013 11:42 AM, Doug Hellmann wrote: On Tue, Jul 16, 2013 at 7:58 AM, Mark McLoughlin mar...@redhat.com mailto:mar...@redhat.com wrote: On Mon, 2013-07-15 at 14:28 -0400, Doug Hellmann wrote: On Mon, Jul 15, 2013 at 11:03 AM, Monty Taylor mord...@inaugust.com mailto:mord...@inaugust.com wrote: I was looking in to dependency processing as part of some pbr change, which got me to look at the way we're doing oslo-config dev requirements again. To start, this email is not about causing us to change what we're doing, only possibly the mechanics of what we put in the requirements.txt file- or to get a more specific example of what we're solving so that I can make a test case for it and ensure we're handling it properly. Currently, we have this: -f http://tarballs..openstack.org/oslo.config/oslo.config-1.2.0a3.tar.gz#egg=oslo.config-1.2..0a3 http://tarballs.openstack.org/oslo.config/oslo.config-1.2.0a3.tar.gz#egg=oslo.config-1.2.0a3 oslo.config=1.2.0a3 As the way to specify to install - 1.2.0a3 of oslo.config. I believe this construct has grown in response to a sequence of issues, but it's complex and fragile, so I'd like to explore what's going on. The simplest answer would be simply to replace it with: http://tarballs.openstack.org/oslo.config/oslo.config-1.2.0a3.tar.gz which will quite happily cause pip to install the contents of that tarball. It does not declare a version, but it's not necessary to, because the tarball has only one version that it is. Is there a problem we have identified where the wrong thing is happening? I've tested that I get the right thing in a virtualenv if I make that change from pip installing a tarball, pip installing the requirements directly and python setup.py install. Is there anything I'm missing? Monty Without the version specifier, we are relying on all projects to install the right version from that tarball link when we run devstack, but we have no guarantee that they are moving to new releases in lockstep. Yep, that's it. The thing to test would be if some projects have the 1.2.0a2 tarball link and an one has the 1.2.0a3 link because it depends on an API that's new in 1.2.0a3. It's worse than that. What gets installed will depend on the order devstack installs the projects and what their respective requirements lists say. It is possible to end up with compatible source code installed, but with a version number that setuptools thinks is not compatible based on projects' requirements. In that case, setuptools may not let us load plugins, so services will start but not actually work. Thank you. This is what I needed here. BTW - I put this up: https://review.openstack.org/#/c/35705/ To take a stab at installing our global requirements list first, and then installing our projects in that environment. I also just made: https://review.openstack.org/#/c/37295/ Which would add oslo.config and oslo.messaging as git repos to the devstack system, so that we can track trunk like we do with the other projects. Awesome, thanks - I've had that on my TODO list for weeks. It's probably a bit early about oslo.messaging, since nothing's using it yet ... but no harm in having it in there. Thanks again, Mark. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] olso-config dev requirement
On Mon, Jul 15, 2013 at 11:03 AM, Monty Taylor mord...@inaugust.com wrote: I was looking in to dependency processing as part of some pbr change, which got me to look at the way we're doing oslo-config dev requirements again. To start, this email is not about causing us to change what we're doing, only possibly the mechanics of what we put in the requirements.txt file- or to get a more specific example of what we're solving so that I can make a test case for it and ensure we're handling it properly. Currently, we have this: -f http://tarballs.openstack.org/oslo.config/oslo.config-1.2.0a3.tar.gz#egg=oslo.config-1.2.0a3 oslo.config=1.2.0a3 As the way to specify to install - 1.2.0a3 of oslo.config. I believe this construct has grown in response to a sequence of issues, but it's complex and fragile, so I'd like to explore what's going on. The simplest answer would be simply to replace it with: http://tarballs.openstack.org/oslo.config/oslo.config-1.2.0a3.tar.gz which will quite happily cause pip to install the contents of that tarball. It does not declare a version, but it's not necessary to, because the tarball has only one version that it is. Is there a problem we have identified where the wrong thing is happening? I've tested that I get the right thing in a virtualenv if I make that change from pip installing a tarball, pip installing the requirements directly and python setup.py install. Is there anything I'm missing? Monty Without the version specifier, we are relying on all projects to install the right version from that tarball link when we run devstack, but we have no guarantee that they are moving to new releases in lockstep. Doug ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
