installation assumes already installed?

[GoogleCodeExporter]

I compile a lot of python modules into a common but non-standard tree 
(including Python 2.7 itself). I make multiple versions available in parallel 
paths, with a common 'most current' version of modules being made available by 
way of symbolic links into one PYTHONPATH.  The way pysam installs is the only 
module I've run across that hasn't fit this model easily, I think due to using 
'distribute'.  Maybe there is something I don't understand about that tool.

What version of the product are you using? On what operating system?

I am using pysam 0.7.4, Python 2.7, Cython 0.17.1 and compiling with gcc 
compilers (4.3.4) on SuSE Linux Enterprise Desktop 11 (x86_64).

What steps will reproduce the problem?
1. download pysam source and unpack into source directory
2. put python (v2.7) in user's search path; the command 'python' will find my 
compiled python2.7.
3. set up environment:
    PYTHONPATH=/apps/current/lib64/python2.7  (this contains Cython and other modules (by way of symbolic links))
3. cd to pysam source directory, do:
    python setup.py build
    rm -rf ${PYSAMDIR}
    python setup.py install --prefix=${PYSAMDIR} --install-lib=${PYSAMDIR}/lib64
(where $PYSAMDIR is the installation location I would like, isolated from other 
modules)

What is the expected output? What do you see instead?
As part of the build, Cython is detected fine; 'distribute-0.6.34' is not 
present, so it is downloaded and put into the source directory.  I suspect that 
some of the issues below are due to 'distribute' not being installed up front.

The above builds but then fails to install on 3 counts:
  1 - I have to add $PYSAMDIR/lib64 to PYTHONPATH or it will fail (see failure message #1 below)
    python setup.py build
    PYTHONPATH=${PYSAMDIR}/lib64:${PYTHONPATH}
    rmdir -rf ${PYSAMDIR}
    python setup.py install --prefix=${PYSAMDIR} --install-lib=${PYSAMDIR}/lib64
  2 - In contrast to other modules I've compiled, I have to explicitly 'export' the PYTHONPATH.  Usually in the context of my bash build scripts, I haven't had to use 'export'.  I guess this implies some subshell or other context is kicking in that doesn't get passed the PYTHONPATH properly.  The error is the same as #1.  So, now I try:
    python setup.py build
    export PYTHONPATH=${PYSAMDIR}/lib64:${PYTHONPATH}
    rmdir -rf ${PYSAMDIR}
    python setup.py install --prefix=${PYSAMDIR} --install-lib=${PYSAMDIR}/lib64
  3 - This still fails, because it expects the '--install-lib' directory to already exist! See failure message #2.  Finally, this works:
    python setup.py build
    export PYTHONPATH=${PYSAMDIR}/lib64:${PYTHONPATH}
    rmdir -rf ${PYSAMDIR}
    mkdir -p ${PYSAMDIR}/lib64
    python setup.py install --prefix=${PYSAMDIR} --install-lib=${PYSAMDIR}/lib64

Once this works, I get a 'clean' install--except, compared to other modules, I 
seem to get more than I care for, including a $PYSAMDIR/bin directory with 
'easy_install' scripts, and lib64 with 'distribute' module and site.py and 
easy_install.pth stuff that I don't care about.

Please provide any additional information below.

failure message #1:
++ python setup.py install 
--prefix=/apps/pkgs/foss/samtools.sourceforge.net/pysam/0.7.4_64-2.7 
--install-lib=/apps/pkgs/foss/samtools.sourceforge.net/pysam/0.7.4_64-2.7/lib64
running install
Checking .pth file support in 
/apps/pkgs/foss/samtools.sourceforge.net/pysam/0.7.4_64-2.7/lib64/
/apps/current/base/python2.7/bin/python -E -c pass
TEST FAILED: /apps/pkgs/foss/samtools.sourceforge.net/pysam/0.7.4_64-2.7/lib64/ 
does NOT support .pth files
error: bad install directory or PYTHONPATH

You are attempting to install a package to a directory that is not
on PYTHONPATH and which Python does not read ".pth" files from.  The
installation directory you specified (via --install-dir, --prefix, or
the distutils default setting) was:

    /apps/pkgs/foss/samtools.sourceforge.net/pysam/0.7.4_64-2.7/lib64/

and your PYTHONPATH environment variable currently contains:

    ''

Here are some of your options for correcting the problem:
[options edited out]

failure message #2:
++ python setup.py install 
--prefix=/apps/pkgs/foss/samtools.sourceforge.net/pysam/0.7.4_64-2.7 
--install-lib=/apps/pkgs/foss/samtools.sourceforge.net/pysam/0.7.4_64-2.7/lib64
running install
error: can't create or remove files in install directory

The following error occurred while trying to add or remove files in the
installation directory:

    [Errno 2] No such file or directory: '/apps/pkgs/foss/samtools.sourceforge.net/pysam/0.7.4_64-2.7/lib64/test-easy-install-26073.write-test'

The installation directory you specified (via --install-dir, --prefix, or
the distutils default setting) was:

    /apps/pkgs/foss/samtools.sourceforge.net/pysam/0.7.4_64-2.7/lib64/

This directory does not currently exist.  Please create it and try again, or
choose a different installation directory (using the -d or --install-dir
option).

Original issue reported on code.google.com by martin.d...@gmail.com on 7 May 2013 at 4:05

[GoogleCodeExporter]

Thanks, I will look into this issue.

I have to admit I am not at home with all the intricacies of distribute but 
will try my best.

Need some time to chew on this, though.

Best wishes,
Andreas

Original comment by andreas....@gmail.com on 26 Jun 2013 at 8:55

• Changed state: Accepted

[GoogleCodeExporter]

The better way to accomplish the above is to use virtualenv.  Setting --prefix 
and --install-lib is a recipe for disaster.

Original comment by kevin.ja...@invitae.com on 26 Jun 2013 at 9:54

[GoogleCodeExporter]

Hi, 

is it still a problem? I have removed distribute as it seems to be deprecated.

We are using pysam in a virtualenv without problems.

Best wishes,
Andreas

Original comment by andreas....@gmail.com on 18 Sep 2013 at 7:07

[GoogleCodeExporter]

This problem, of needing the --install-lib to exist before installing, seems to 
be a general one that I am finding for a host of python modules that use 
whatever mechanism (distribute? recent setuptools?) assumes it will use *.pth 
files and/or easy_install.  Since I am installing and maintaining a central 
application stree for a number of users, virtualenv isn't really a useful 
option for me.  I've worked around it by simply  making the directory first, 
and adding that directory to the PYTHONPATH variable before installing.  I do 
other things on the backend by way of symbolic links so everything works out. 
Regarding #2 in my original message, I don't have to export PYTHONPATH, I just 
precede the install with 'env PYTHONPATH=...

I *did* just download the latest version, and it is still using distribute, not 
only that it is using an old one:
Downloading 
http://pypi.python.org/packages/source/d/distribute/distribute-0.6.34.tar.gz

(yes, distribute *is* deprecated now; there is a wrapper verson 0.7.3 which is 
the last version, wraps setuptools, and which I already have installed, so I 
don't know why it grabs this version).  I'm still trying to figure it out, your 
setup.py wants to import distribute_setup.

Original comment by martin.d...@gmail.com on 2 Oct 2013 at 1:57

[GoogleCodeExporter]

Thanks, I have released a new version 0.7.6 without distribute.

Please let me know if it still tries to use distribute.

Best wishes,
Andreas

Original comment by andreas....@gmail.com on 2 Oct 2013 at 7:10

[GoogleCodeExporter]

that worked great, thanks!

Original comment by martin.d...@gmail.com on 2 Oct 2013 at 8:59

[GoogleCodeExporter]

Thanks!

Original comment by andreas....@gmail.com on 24 Nov 2013 at 10:21

• Changed state: Fixed