On Thu, Feb 11, 2016 at 04:46:39AM +0000, Jeremy Stanley wrote: > On 2016-02-11 14:41:03 +1100 (+1100), Tony Breeds wrote: > [...] > > Okay We'll need to think about that one as the contrainst in > > stable/kilo can be bogus, sometime we have a version in contraints > > that isn't valid compared to g-r > [...] > > Oh, right since there's an upper-constraints.txt in stable/kilo of > openstack/requirements we're building and serving wheels of > whatever's listed in that too. If that file isn't actually relevant > on the branch, it may make more sense to delete it from the repo?
Possibly deleting it would make sense, I'll leave that for another thread ;P but a quick grep indicates it's probably safe. > Regardless, if jobs on stable/kilo of projects aren't using those > versions of packages, then the wheels of them aren't hurting > anything they're just not going to help either. Thanks for the explanation. > > Right I was thinking of $library adds a release I rin tox > > (uncontstrained) at home and get that new release I then run the > > same (unconstrained) test in the gate and get the wheel frmo the > > cache. Just somethign to keep in mind not a problem as such. > [...] > > Unconstrained jobs will mostly benefit from our custom wheel mirror > if upper-constraints.txt in openstack/requirements and the > requirements files in individual repos are being kept current. If > there's a newer version of some dependency than is listed in the > constraints file but is still within the valid range in a project's > requirements file then unconstrained jobs for that repo will end up > grabbing the newer sdist or (if available) wheel from our full PyPI > mirrors instead of the custom wheel mirror. Ok, Thanks for clarifying that. > In short, constrained jobs will benefit greatly, especially if they > have dependencies which link external C libs and would normally take > a long time to compile. Unconstrained jobs for repos participating > in global requirements sync/enforcement will benefit a lot of the > time as long as their requirements and the constraints list updates > are being kept up with. Jobs for repos not participating in global > requirements may still benefit if they share some requirement > versions with things which are listed in the constraints file on > some branch (or were at some point in recent history). Woot! I don't want any of these questions to imply dissatisfaction. Quite the opposite I think it's a great thing I'm just trying to understand how it all works. Yours Tony.
signature.asc
Description: PGP signature
__________________________________________________________________________ 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