On 12/07/12 19:07, Olemis Lang wrote:
I think that to run through virtualenv you would have to resort to the kind
of trickery that I was using in the old installer.py but I am not convinced
that is the best plan.
... well ... for the moment I'll stick to using virtualenv . I tried
to use virtual_python.py script before but it didn't work . So I'm
hoping I can assume as a precondition that virtualenv is installed in
system python lib folder ... and won't hurt anybody's feelings ...
;)
I had no idea what virtual_python.py was about actually. I wondered why
you were trying that.
fact is that testrun is a «public» site used to automate builds for
FLOSS projects powered by python . This means :
1. no VM under my control connected in there
2. better limit the scope of side effects when running build jobs
as this may affect others
2a. ... hence try not to install nothing globally (I even think user
running Jenkins server has no permission to do that either)
2b. ... and protect build scripts against side effects introduced
by others (... if any ...)
2c. e.g. --no-site-packages
3. maybe it's accurate to assume that python & virtualenv
will be pre-installed using global python interpreter
in the slave
Yes, under these circumstances I would expect that virtualenv and pip
are effectively available in the first place. But even if it makes use
of some other system, if you are able to do pip installs or
easy_installs without sudo access then you should be fine. I would also
expect that the slave would effectively be back to the original state
when it next runs.
As I mentioned in my follow up message, it looks like the bigger problem
is the apparently missing svn command. Given that it was possible for
the bloodhound repository to be updated, there must be a way to check
out the other dependencies. You could add other svn checkout or update
steps and then use a different pip requirements file.
Cheers,
Gary
