Right now we do something that upstream pip considers wrong: we make our requirements.txt be our install_requires.
Upstream there are two separate concepts. install_requirements, which are meant to document what *must* be installed to import the package, and should encode any mandatory version constraints while being as loose as otherwise possible. E.g. if package A depends on package B version 1.5 or above, it should say B>=1.5 in A's install_requires. They should not specify maximum versions except when that is known to be a problem: they shouldn't borrow trouble. deploy requirements - requirements.txt - which are meant to be *local to a deployment*, and are commonly expected to specify very narrow (or even exact fit) versions. What pbr, which nearly if not all OpenStack projects use, does, is to map the contents of requirements.txt into install_requires. And then we use the same requirements.txt in our CI to control whats deployed in our test environment[*]. and there we often have tight constraints like seen here - http://git.openstack.org/cgit/openstack/requirements/tree/global-requirements.txt#n63 I'd like to align our patterns with those of upstream, so that we're not fighting our tooling so much. Concretely, I think we need to: - teach pbr to read in install_requires from setup.cfg, not requirements.txt - when there are requirements in setup.cfg, stop reading requirements.txt - separate out the global intall_requirements from the global CI requirements, and update our syncing code to be aware of this Then, setup.cfg contains more open requirements suitable for being on PyPI, requirements.txt is the local CI set we know works - and can be much more restrictive as needed. Thoughts? If there's broad apathy-or-agreement I can turn this into a spec for fine coverage of ramifications and corner cases. -Rob -- Robert Collins <rbtcoll...@hp.com> Distinguished Technologist HP Converged Cloud __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
