[TIP] tox/ShiningPanda/Jenkins - Permission denied during VirtualEnv setup

Chris Withers chris at simplistix.co.uk
Tue Jul 3 10:36:30 PDT 2012


Hi Holger,

(CC'ing in the virtualenv group as I suspect someone there may be able 
to shed more light on this...)

On 03/07/2012 18:22, holger krekel wrote:
>> However, still struggling with this one, which is affecting all of
>> my tox jobs:
>>
>> http://lists.idyll.org/pipermail/testing-in-python/2012-July/005020.html
>
> It looks like some kind of an integration problem.

Indeed, I have a suspicion that it's because I have set up virtualenvs 
for ShingingPanda to use as it's "python installations" (because on both 
Debian and Mac OS X the system pythons are polluted...) and it looks 
like when virtualenv tries to create another virtualenv from the 
original one, it does so by symlinking parts of it (the originals are 
rightly owned by root, I don't want *anything* messing with them) and 
then tripping itself up by trying to overwrite distutils/__init__.py 
(and I still have no idea why it would ever want to do that)

Can any virtualenv folks shed light on whether the above sounds 
plausible and if anything has changed in this area in the last few months?

Picking up on Holger's comments:
> Tox invokes virtualenv
> and virtualenv decides it needs to overwrite distutils/__init__.py

Indeed, does anyone know why it wants to do that?

> and it
> can't.

Good! (given the symlinking... ;-) )

>  So either virtualenv didn't decide this before or the file was
> writable.

I suspect the former, can any virtualenv guys confirm?

> If you or Olivier have shell-access to the machine in question
> i'd recommend trying to issue the failing commandline and go from there.

I have shell access to all the machines, but I'm not sure what running 
the same command again will verify other than that it does indeed result 
in the permission error...

> As a sidenote, i am wondering if tox should require exact versions of
> virtualenv, pip and distribute and do new minor releases when new versions
> come out.  Ideally, such a release process should happen automatically ...
> Up until then i guess we need to live with suddenly appearing problems.

That's certainly one approach. In my case, I just intend to start doing 
a weekly run of all my Jenkins jobs in addition to the runs triggered by 
commits, it seems the only really safe way to make sure changes to 
dependencies don't cause problems (this and the now-fixed windows 
problems have bitten me, along with a slew on zope packages becoming 
incompatible with Python 2.5 in their latest releases)

cheers,

Chris

-- 
Simplistix - Content Management, Batch Processing & Python Consulting
             - http://www.simplistix.co.uk



More information about the testing-in-python mailing list