<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Apr 12, 2015 at 3:43 PM, Robert Collins <span dir="ltr"><<a href="mailto:robertc@robertcollins.net" target="_blank">robertc@robertcollins.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Right now we do something that upstream pip considers wrong: we make<br>
our requirements.txt be our install_requires.<br>
<br>
Upstream there are two separate concepts.<br>
<br>
install_requirements, which are meant to document what *must* be<br>
installed to import the package, and should encode any mandatory<br>
version constraints while being as loose as otherwise possible. E.g.<br>
if package A depends on package B version 1.5 or above, it should say<br>
B>=1.5 in A's install_requires. They should not specify maximum<br>
versions except when that is known to be a problem: they shouldn't<br>
borrow trouble.<br>
<br>
deploy requirements - requirements.txt - which are meant to be *local<br>
to a deployment*, and are commonly expected to specify very narrow (or<br>
even exact fit) versions.<br></blockquote><div><br></div><div>Link to where this is documented? If this isn't written down anywhere, then that should be a pre-requisite to this conversation. Get upstream to document this.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
What pbr, which nearly if not all OpenStack projects use, does, is to<br>
map the contents of requirements.txt into install_requires. And then<br>
we use the same requirements.txt in our CI to control whats deployed<br>
in our test environment[*]. and there we often have tight constraints<br>
like seen here -<br>
<a href="http://git.openstack.org/cgit/openstack/requirements/tree/global-requirements.txt#n63" target="_blank">http://git.openstack.org/cgit/openstack/requirements/tree/global-requirements.txt#n63</a><br>
<br>
I'd like to align our patterns with those of upstream, so that we're<br>
not fighting our tooling so much.<br>
<br>
Concretely, I think we need to:<br>
 - teach pbr to read in install_requires from setup.cfg, not requirements.txt<br>
 - when there are requirements in setup.cfg, stop reading requirements.txt<br>
 - separate out the global intall_requirements from the global CI<br>
requirements, and update our syncing code to be aware of this<br>
<br>
Then, setup.cfg contains more open requirements suitable for being on<br>
PyPI, requirements.txt is the local CI set we know works - and can be<br>
much more restrictive as needed.<br>
<br>
Thoughts? If there's broad apathy-or-agreement I can turn this into a<br>
spec for fine coverage of ramifications and corner cases.<br>
<br>
-Rob<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Robert Collins <<a href="mailto:rbtcollins@hp.com">rbtcollins@hp.com</a>><br>
Distinguished Technologist<br>
HP Converged Cloud<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</font></span></blockquote></div><br></div></div>