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? 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. > 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. 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). -- Jeremy Stanley __________________________________________________________________________ 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