On 09/25/2013 12:20 AM, Monty Taylor wrote: > > > On 09/24/2013 12:11 PM, Thomas Goirand wrote: >> Hi Monty, >> >> On 09/24/2013 09:44 AM, Monty Taylor wrote: >>> Instead of: >>> >>> "python setup.py install" >>> >>> Run: >>> >>> "pip install ." >> >> No way that this happens on the packaging side. Buildd have no network >> access (on purpose), and we must not do any network access when building. >> >> So I wonder what this post is trying to achieve. > > This post has nothing to do with packaging. The OpenStack project does > not produce packages. > > This is informational for people who are already running setup.py > install, suggesting that they use pip install . instead. > > If, however, you are in a packaging situation and you are running > setup.py install as part of your packaging scripts such as in your > debian/rules file or your rpm spec file, continuing to use setup.py > install should have no negative effects, as all of the requirements > processing should be avoided due to the system packaging having taken > care of it already, so the evil that is easy_install will not be invoked. > > Further, all debian/rules and rpm spec files that are packaging > openstack project should really add the SKIP_PIP_INSTALL env var. This > will turn off the additional pip operations that pbr does - which are > again pointless in a distro-packaging world.
Hi, Thanks for this clarification. You got me scared!!! :) BTW, as I wrote already, I'm not really a fan of adding SKIP_PIP_INSTALL, because if I do, I might not see the errors due to missing dependencies. If there's a missing dependency and pip tries to install it, it will break the build process, which really is what I want. Or is it that SKIP_PIP_INSTALL still does a check to see if dependencies are there? If that's not the case, then I would find it really nice if it was possible to have a mode in which there is a pip check that does a *hard break* error, and just stops the build process (no need to wait until dpkg-buildpackage sees that there's an egg-info folder that shouldn't be there). Any thoughts on this? Thomas _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
