On Sun, Apr 12, 2015 at 3:43 PM, Robert Collins <robe...@robertcollins.net> wrote:
> 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. > 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. > > 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 >
__________________________________________________________________________ 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
