[Starlingx-discuss] [build-report] STX_build_docker_images - Build # 32 - Still Failing!

[Penney, Don]

I think it's more than just updating the global-requirements.txt file. The problem we hit is with things like tox and loci that use virtualenv, using virtualenv to access the latest pip for installing modules. Maybe there's a way to lock down what virtualenv enables?

-----Original Message-----
From: Dean Troyer [mailto:dtroyer at gmail.com] 
Sent: Wednesday, January 23, 2019 12:18 PM
To: Little, Scott
Cc: starlingx
Subject: Re: [Starlingx-discuss] [build-report] STX_build_docker_images - Build # 32 - Still Failing!

On Wed, Jan 23, 2019 at 9:40 AM Scott Little <scott.little at windriver.com> wrote:
> 2) A new pip was pushed upstream that cause a lot of breakage, and not just for us.  I'm told upstream has pushed a fix, so we'll try again today.  Longer term, can we lock down pip?  Do we need to mirror pypi?  TBD.

We may want to mirror pypi but for other (performance/stable access)
reasons so that is a separate thing.

OpenStack spent some time capping Python versions of things for this
reason, and has reverted to only doing that in response to specific
breakages, like pip 19.0.  In this case it may have been fixed before
some folks noticed and the only result with be adding "!19.0,>=19.0.1"
in the global-requirements file for pip. (Actually, as of my writing
this no change has been proposed for pip, probably because 19.0 is not
going to be picked up by anything automatically with the release of
19.0.1).

The reasoning is that you want to know about things like this sooner
than later and work to get them fixed, or identify workarounds,
otherwise you find yourself in a hole of debt to move forward, and
once the mass of interlocking dependencies move far enough it can
become a pretty big hole.

Once you enter stable release territory that changes as you often do
not want to move forward and break the stable release, so our Pike
build may have wanted to hard-cap pip, but that is a short-timers
issue for us now.  Once we're only on master I think following
upstream is better in the long run.

dt

-- 

Dean Troyer
dtroyer at gmail.com

_______________________________________________
Starlingx-discuss mailing list
Starlingx-discuss at lists.starlingx.io
http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss