[Bigjob-users] BigJob installation page comments

[Andre Luckow]

Hi Yaakoub,
I understand your concern regarding the user-level Python
installation. The documentation just explains how a user can install
BigJob in user-space. If possible, BJ should be installed in
system-space (e.g. the CSA space). It is as easy as typing:

easy_install bigjob

This will also pull in all dependencies.

Unfortunately, BJ is often not installed in system-space. The
bootstrap script can install BJ in any location using any Python that
you would like to use:

<path-to-python-of-your-choice>/bin/python boostrap-bigjob.py <target-location>

The script will create a virtualenv for BJ. This is better both for
the user, which is only required to use this one command line, and for
the development/maintainability of BigJob. If a user has the
particular requirement of using a system-level Python, he can also go
through the pain of manually installing the BJ package and messing
around with the PYTHONPATH. To do so, BJ needs to checked out of the
SVN; then just execute:

python setup.py install --prefix=<target-dir>

We will add an explanation of this option to the web page.

Hope that explains the design decision.

Best,
Andre

On Fri, Oct 14, 2011 at 10:46 PM, Yaakoub El Khamra <yelkhamra at gmail.com> wrote:
> I have a few comments regarding the bigjob documentation, particularly
> the install page:
> http://faust.cct.lsu.edu/trac/bigjob/wiki/install
>
> A fair amount of the instructions are regarding softenv, which is
> phased out on xsede/teragrid resources. You might want to move this
> down a bit.
>
> The easy_install and virtualenv are not installed by default on most
> xsede/teragrid machines. This means the user will run into errors
> trying to install that way.
>
> The bootstrap works but needs tweaking. I need to be able to specify
> my own python for bigjob to use and install it in my own location as
> opposed to a .python directory in $HOME. There are many problems with
> having python code installed to $HOME, mostly relating to performance,
> so let's not do that.
>
> Otherwise, the documentation is fine in my opinion.
>
> Regards
> Yaakoub El Khamra
>