Sorry.. I only spotted this message after my last reply.
On 12/07/12 19:29, Olemis Lang wrote:
On 7/12/12, Gary Martin <[email protected]> wrote:
Actually, it sort of looks like the commands might have been running in
what is effectively a virtualenv anyway.
yes ;)
they are using python interpreter @
/path/to/jenkins/buildjob/ws/installer/bloodhound/bin/python inside
virtualenv @ /path/to/jenkins/buildjob/ws/installer/bloodhound
Good.. you don't need another virtualenv and there is no need to
activate it so don't worry about the source command replacement I
mentioned. So.. is pip already installed too?
it looks like the ImportError exception should be taken at face
value.. That trac is not actually installed.
well ... I noticed that but I thought that step was part of the
installer as well , that's why I asked .
It is a part of the bloodhound_setup.py command but it failed for a
valid reason.
In any case Bloodhound works on top of a custom Trac install enhanced
with some patches (... as we already know ...) so I wonder whether it
will be a good idea to make that distinction explicit in the installer
in order to ensure users will be using the correct code under-the-hood
Well, as the requirements file provides the correct trac, that is not
strictly necessary but it may be worth thinking about.
And closer at the output of
the pip install command, it fails with:
Cannot find command 'svn'
That should be happening due to the fact that build job is not aware
of system PATH . Setting it should be enough ... but that one , well ,
I didn't notice before . Thanks for the pointer .
Ah, excellent. That sounds like a good potential way to fix then.
Before it can actually starts to install the packages. At the moment
TracAccountManager, TracThemeEngine and TracPermRedirect are all
specified to be pulled from the trac-hacks svn server. We would have to
check if we can get appropriate versions elsewhere if we want to change
this.
So , fresh versions of plugins @ t.h.o will be considered stable ?
No, I don't consider them stable.
Maybe we should tag (... even if not in t.h.o svn repos then at least
in installer script ...) versions considered stable once we know they
work (<= e.g. once build jobs report everything is ok with it ;) .
Yes, this is the idea.
Cheers,
Gary
