Re: [PATCH 1/1] python3-native: Fix pip install issue due to unclean build directory

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Fri, 2015-04-17 at 19:19 -0500, Alejandro Hernandez wrote:
> On 17/04/15 16:50, Richard Purdie wrote:
> > On Thu, 2015-04-16 at 09:45 +0000, Alejandro Hernandez wrote:
> >> When installing python3-native sometimes pips default build
> >> directory (which is on the host and is user dependant) is left unclean,
> >> due to this, when python3-core is being installed it tries to use
> >> the same directory producing an error, this explicitly removes
> >> what the previous installation might have left behind, fixing the issue.
> >>
> >> Signed-off-by: Alejandro Hernandez <alejandro.hernandez@linux.intel.com>
> >> ---
> >>   .../python/python3-native_3.4.2.bb                 |  1 +
> >>   .../python3/pip_build_directory_unclean.patch      | 28 ++++++++++++++++++++++
> >>   2 files changed, 29 insertions(+)
> >>   create mode 100644 meta/recipes-devtools/python/python3/pip_build_directory_unclean.patch
> > The problem here is that two builds of python3-native could be happening
> > on the same system at the same time. In fact I'd bet that is why its
> > breaking on the autobuilder. Can we not tell it to use something in
> > WORKDIR as its temp directory instead?
> >
> > Cheers,
> >
> > Richard
> Hmm, that's potentially what is happening, in fact, my first thought was 
> to do that and use something within the WORKDIR, but I wasn't able to do 
> that because they do something weird to install pip, they bootstrap the 
> installation and they use python wheels, so the actual part of the code 
> where one could specify a different build directory for pip is inside 
> one of the wheels, making it complicated to modify.
> The only other thing that occurs to me would be to just make it sleep or 
> make it wait somehow (we could modify the queue?) until the directory is 
> empty.
> 
> I still think this should work, I only saw cases where the build 
> directory is left with one empty file, another reason why I decided to 
> explicitly delete it instead of forcing it to delete everything inside 
> the directory, disabling pip is not an option because it is required 
> since python 3.4 as I stated on the upgrade patch, we could try this, 
> and if it doesn't work I'll find another workaround, but let me know 
> what you think.

I tried it on the autobuilder and it failed again. I think part of the
problem is that this part of the process runs under pseudo so it thinks
its root, yet can't clear root's pip directory in /tmp.

I suspect we are going to have to tell pip to use WORKDIR somehow, even
if we have to patch it to take some kind of prompt from the environment
for example.

Cheers,

Richard