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.

Attachment: 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

Reply via email to