[openstack-dev] All hail the new per-region pypi, wheel and apt mirrors
tony at bakeyournoodle.com
Thu Feb 11 06:06:53 UTC 2016
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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 473 bytes
Desc: not available
More information about the OpenStack-dev