On Tue, 14 Apr 2015, Joe Gordon wrote:
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.
I don't know where it is documented but this was the common wisdom I
knew from the Python community since long before coming to the
OpenStack community. To me, seeing a requirements.txt in a repo that
represents a class of an app or library (rather than an instance of
a deployment) was quite a surprise.
(This doesn't have that much bearing on the practical aspects of
this conversation, just wanted to add some anecdata that the precedent
described above is not weird or alien in any way.)
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent
__________________________________________________________________________
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
