Skip Menu | Logged in as guest | Logout
 
Ticket metadata
Id: 3299
Status: resolved
Priority: 3/0
Queue: vdt-support

Fixed in: (no value)
Fix scheduled: CUR

Owner: Alain Roy
Requestors: rwg@hep.uchicago.edu
Cc:
AdminCc:

More about rwg@hep.uchicago.edu
Comments about this user:
No comment entered about this user
This user's 10 highest priority tickets:
Groups this user belongs to:
  • Everyone

New reminder:

Created: Thu Feb 07 18:26:25 2008
Starts: Not set
Started: Not set
Last Contact: Fri Apr 04 11:19:26 2008
Due: Not set
Closed: Wed Apr 23 15:25:19 2008
Updated: Wed Apr 23 15:25:19 2008 by roy



History Brief headersFull headers
CC: MWT2 <mwt2-core-l@LISTSERV.INDIANA.EDU>, osg-vtb@OPENSCIENCEGRID.ORG
Subject: Problem with osg-client
Date: Thu, 07 Feb 2008 18:06:59 -0600
To: vdt-support@OPENSCIENCEGRID.ORG
From: Rob Gardner <rwg@hep.uchicago.edu>
Download (untitled) / with headers
text/plain 619b
Alain,

We ran across a problem with osg-client - it adds to
the python path a non-existent directory:

#
#-- package /share/osg-client:http://vdt.cs.wisc.edu/vdt_181_cache:Globus-Core
#
PYTHONPATH="/share/osg-client/globus/lib/python:$PYTHONPATH"
export PYTHONPATH
PYTHONPATH="/share/osg-client/globus/lib64/python:$PYTHONPATH"
export PYTHONPATH
#

/share/osg-client/globus/lib/ is there, but /share/osg-client/globus/
lib64
does not exist.

Note - this was installed on a 64bit machine with a 32 bit OS (SL 4.5).

(the client was installed in the usual way w/ pacman, no special
flags, $pacman -get OSG:client)

Rob
Download (untitled) / with headers
text/plain 921b
Yeah, I set both the 32 bit and 64 bit path for simplicity (less
conditional code), because I didn't think it mattered.

Is this an aesthetic problem, or does it cause deeper problems?

-alain

> [rwg@hep.uchicago.edu - Thu Feb 07 18:26:25 2008]:
>
> Alain,
>
> We ran across a problem with osg-client - it adds to
> the python path a non-existent directory:
>
> #
> #-- package /share/osg-
> client:http://vdt.cs.wisc.edu/vdt_181_cache:Globus-Core
> #
> PYTHONPATH="/share/osg-client/globus/lib/python:$PYTHONPATH"
> export PYTHONPATH
> PYTHONPATH="/share/osg-client/globus/lib64/python:$PYTHONPATH"
> export PYTHONPATH
> #
>
> /share/osg-client/globus/lib/ is there, but /share/osg-client/globus/
> lib64
> does not exist.
>
> Note - this was installed on a 64bit machine with a 32 bit OS (SL
> 4.5).
>
> (the client was installed in the usual way w/ pacman, no special
> flags, $pacman -get OSG:client)
>
> Rob
CC: MWT2 List <mwt2-core-l@LISTSERV.INDIANA.EDU>
Subject: Re: [vdt-support #3299] Problem with osg-client
Date: Thu, 07 Feb 2008 22:33:54 -0600
To: vdt-support@OPENSCIENCEGRID.ORG
From: Rob Gardner <rwg@hep.uchicago.edu>
Download (untitled) / with headers
text/plain 1.5k
Alain

It matters, because it gets put into the python path of
a Panda application (pathena). That program senses
the fact that ../globus/lib64 doesn't exist, and quits.

I think people have not complained about this since
they typically use glite middleware (sitting in an AFS
area at either CERN or BNL) for the client tools.
I am trying to establish a "clean" interactive
environment for US ATLAS using OSG client, so
this is an obstacle to that.

Rob



On Feb 7, 2008, at 9:16 PM, Alain Roy via RT wrote:

> Yeah, I set both the 32 bit and 64 bit path for simplicity (less
> conditional code), because I didn't think it mattered.
>
> Is this an aesthetic problem, or does it cause deeper problems?
>
> -alain
>
>> [rwg@hep.uchicago.edu - Thu Feb 07 18:26:25 2008]:
>>
>> Alain,
>>
>> We ran across a problem with osg-client - it adds to
>> the python path a non-existent directory:
>>
>> #
>> #-- package /share/osg-
>> client:http://vdt.cs.wisc.edu/vdt_181_cache:Globus-Core
>> #
>> PYTHONPATH="/share/osg-client/globus/lib/python:$PYTHONPATH"
>> export PYTHONPATH
>> PYTHONPATH="/share/osg-client/globus/lib64/python:$PYTHONPATH"
>> export PYTHONPATH
>> #
>>
>> /share/osg-client/globus/lib/ is there, but /share/osg-client/globus/
>> lib64
>> does not exist.
>>
>> Note - this was installed on a 64bit machine with a 32 bit OS (SL
>> 4.5).
>>
>> (the client was installed in the usual way w/ pacman, no special
>> flags, $pacman -get OSG:client)
>>
>> Rob
>
>
> --
> View ticket at <http://vdt.cs.wisc.edu/rt/Ticket/Display.html?
> user=guest&pass=guest&id=3299>
> VDT Support, vdt-support@ivdgl.org
> [rwg@hep.uchicago.edu - Thu Feb 07 22:36:23 2008]:
>
> Alain
>
> It matters, because it gets put into the python path of
> a Panda application (pathena). That program senses
> the fact that ../globus/lib64 doesn't exist, and quits.
>
> I think people have not complained about this since
> they typically use glite middleware (sitting in an AFS
> area at either CERN or BNL) for the client tools.
> I am trying to establish a "clean" interactive
> environment for US ATLAS using OSG client, so
> this is an obstacle to that.

Ah, I see.

Can you clarify if this is a Python problem or a Panda problem? I ran a
basic Python script with a PYTHONPATH that included a non-existant
directory and it didn't have any problems.

I think I know how to address this. How serious is this for you? Do we
need to get a fix into VDT 1.8.1, or is the next release of the VDT soon
enough for you?

As a workaround, there is a place you can override the PYTHONPATH set by
the VDT to remove the bad directory. If you want help with this option,
I'm happy to help work it out.

-alain
Subject: Re: [vdt-support #3299] Problem with osg-client
Date: Mon, 11 Feb 2008 10:23:44 -0600
To: vdt-support@OPENSCIENCEGRID.ORG
From: Rob Gardner <rwg@hep.uchicago.edu>
Download (untitled) / with headers
text/plain 1.9k
Alain,

Panda catches this and throws an error. I have a work
around -- I dump the path, delete the reference
to the non-existent directory, and reassign the
PYTHONPATH. Its rather messy.

I would like to encourage my usatlas colleagues to use
osg-client rather than lcg-client... just in the mail
over the weekend was someone telling us atlas
physicists to setup their grid environment with:

====
6. Setup Grid and do a "grid-proxy-init":
$ source /afs/usatlas.bnl.gov/lcg/current/etc/profile.d/grid_env.sh
$ grid proxy-init
====

I'd like to correct this, to have them install osg-client,
but at the moment Panda would fail for a trivial reason.

Rob




On Feb 8, 2008, at 2:25 PM, Alain Roy via RT wrote:

>> [rwg@hep.uchicago.edu - Thu Feb 07 22:36:23 2008]:
>>
>> Alain
>>
>> It matters, because it gets put into the python path of
>> a Panda application (pathena). That program senses
>> the fact that ../globus/lib64 doesn't exist, and quits.
>>
>> I think people have not complained about this since
>> they typically use glite middleware (sitting in an AFS
>> area at either CERN or BNL) for the client tools.
>> I am trying to establish a "clean" interactive
>> environment for US ATLAS using OSG client, so
>> this is an obstacle to that.
>
> Ah, I see.
>
> Can you clarify if this is a Python problem or a Panda problem? I
> ran a
> basic Python script with a PYTHONPATH that included a non-existant
> directory and it didn't have any problems.
>
> I think I know how to address this. How serious is this for you? Do we
> need to get a fix into VDT 1.8.1, or is the next release of the VDT
> soon
> enough for you?
>
> As a workaround, there is a place you can override the PYTHONPATH
> set by
> the VDT to remove the bad directory. If you want help with this
> option,
> I'm happy to help work it out.
>
> -alain
>
>
> --
> View ticket at <http://vdt.cs.wisc.edu/rt/Ticket/Display.html?
> user=guest&pass=guest&id=3299>
> VDT Support, vdt-support@ivdgl.org
CC: Rob Gardner <rwg@hep.uchicago.edu>
Subject: Re: [vdt-support #3299] Problem with osg-client
Date: Thu, 13 Mar 2008 05:24:14 -0500
To: vdt-support@OPENSCIENCEGRID.ORG
From: Rob Gardner <rwg@hep.uchicago.edu>
Download (untitled) / with headers
text/plain 2.1k
Alain,

I'm not sure where we left this. Is this fixed in the latest
VDT client?

thanks,

Rob



On Feb 11, 2008, at 10:23 AM, Rob Gardner wrote:

> Alain,
>
> Panda catches this and throws an error. I have a work
> around -- I dump the path, delete the reference
> to the non-existent directory, and reassign the
> PYTHONPATH. Its rather messy.
>
> I would like to encourage my usatlas colleagues to use
> osg-client rather than lcg-client... just in the mail
> over the weekend was someone telling us atlas
> physicists to setup their grid environment with:
>
> ====
> 6. Setup Grid and do a "grid-proxy-init":
> $ source /afs/usatlas.bnl.gov/lcg/current/etc/profile.d/grid_env.sh
> $ grid proxy-init
> ====
>
> I'd like to correct this, to have them install osg-client,
> but at the moment Panda would fail for a trivial reason.
>
> Rob
>
>
>
>
> On Feb 8, 2008, at 2:25 PM, Alain Roy via RT wrote:
>
>>> [rwg@hep.uchicago.edu - Thu Feb 07 22:36:23 2008]:
>>>
>>> Alain
>>>
>>> It matters, because it gets put into the python path of
>>> a Panda application (pathena). That program senses
>>> the fact that ../globus/lib64 doesn't exist, and quits.
>>>
>>> I think people have not complained about this since
>>> they typically use glite middleware (sitting in an AFS
>>> area at either CERN or BNL) for the client tools.
>>> I am trying to establish a "clean" interactive
>>> environment for US ATLAS using OSG client, so
>>> this is an obstacle to that.
>>
>> Ah, I see.
>>
>> Can you clarify if this is a Python problem or a Panda problem? I
>> ran a
>> basic Python script with a PYTHONPATH that included a non-existant
>> directory and it didn't have any problems.
>>
>> I think I know how to address this. How serious is this for you? Do
>> we
>> need to get a fix into VDT 1.8.1, or is the next release of the VDT
>> soon
>> enough for you?
>>
>> As a workaround, there is a place you can override the PYTHONPATH
>> set by
>> the VDT to remove the bad directory. If you want help with this
>> option,
>> I'm happy to help work it out.
>>
>> -alain
>>
>>
>> --
>> View ticket at <http://vdt.cs.wisc.edu/rt/Ticket/Display.html?user=guest&pass=guest&id=3299
>> >
>> VDT Support, vdt-support@ivdgl.org
>
Subject: [vdt-support #3299] SVN commit, rev 7447
To: vdt-support@cs.wisc.edu
From: roy@cs.wisc.edu
Download (untitled) / with headers
text/plain 317b
Commit comment:
Tweaked to only set lib or lib64, depending on the platform.
We do this to work around a problem in Panda that makes it fail if
PYTHONPATH includes a directory that doesn't exist.


Changed files:
U vdt/trunk/PyGlobus/PyGlobus.pacman

To generate a diff:
svn diff -c 7447 file:///p/vdt/workspace/svn
Subject: Re: [vdt-support #3299] Problem with osg-client
Date: Fri, 04 Apr 2008 09:56:09 -0500
To: vdt-support@OPENSCIENCEGRID.ORG
From: Alain Roy <roy@cs.wisc.edu>
Download (untitled) / with headers
text/plain 721b
On Mar 13, 2008, at 5:30 AM, rwg@hep.uchicago.edu via RT wrote:

> http://vdt.cs.wisc.edu/rt/Ticket/Display.html?id=3299
>
> Alain,
>
> I'm not sure where we left this. Is this fixed in the latest
> VDT client?

Not yet, sorry.

I just tried out a fix for this in the upcoming VDT 1.10.0, but it
turned out to be trickier than I expected. Apparently on different
platforms, PyGlobus will install into lib64 or lib, and I don't know
what the discriminating factor is. So I haven't figured out a way to
fix it.

I'm still confused why this causes a problem for Panda. Other Python
programs don't seem to have a problem when PYTHONPATH contains extra
paths. Can you help me understand what is going on?

-alain
Subject: [vdt-support #3299] SVN commit, rev 7455
To: vdt-support@cs.wisc.edu
From: roy@cs.wisc.edu
Download (untitled) / with headers
text/plain 296b
Commit comment:
Trying a more thorough check for which directory PyGlobus is installed
in. Apparently on some 64-bit platforms it ends up in lib64, and
others lib. Whatever.


Changed files:
U vdt/trunk/PyGlobus/PyGlobus.pacman

To generate a diff:
svn diff -c 7455 file:///p/vdt/workspace/svn
Subject: [vdt-support #3299] SVN commit, rev 7456
To: vdt-support@cs.wisc.edu
From: roy@cs.wisc.edu
Download (untitled) / with headers
text/plain 155b
Commit comment:
Fixed stupid typo


Changed files:
U vdt/trunk/PyGlobus/PyGlobus.pacman

To generate a diff:
svn diff -c 7456 file:///p/vdt/workspace/svn
Subject: [vdt-support #3299] SVN commit, rev 7458
To: vdt-support@cs.wisc.edu
From: roy@cs.wisc.edu
Download (untitled) / with headers
text/plain 244b
Commit comment:
Back-port of fix from trunk (VDT 1.10.0) to set lib and lib64
better. See ticket for details.


Changed files:
U vdt/branches/vdt-1.8.1/PyGlobus/PyGlobus.pacman

To generate a diff:
svn diff -c 7458 file:///p/vdt/workspace/svn
Subject: Re: [vdt-support #3299] Problem with osg-client
Date: Fri, 04 Apr 2008 11:09:45 -0500
To: vdt-support@OPENSCIENCEGRID.ORG
From: Alain Roy <roy@cs.wisc.edu>
Download (untitled) / with headers
text/plain 917b
>
> On Mar 13, 2008, at 5:30 AM, rwg@hep.uchicago.edu via RT wrote:
>
>> http://vdt.cs.wisc.edu/rt/Ticket/Display.html?id=3299
>>
>> Alain,
>>
>> I'm not sure where we left this. Is this fixed in the latest
>> VDT client?
>
> Not yet, sorry.
>
> I just tried out a fix for this in the upcoming VDT 1.10.0, but it
> turned out to be trickier than I expected. Apparently on different
> platforms, PyGlobus will install into lib64 or lib, and I don't know
> what the discriminating factor is. So I haven't figured out a way to
> fix it.
>
> I'm still confused why this causes a problem for Panda. Other Python
> programs don't seem to have a problem when PYTHONPATH contains extra
> paths. Can you help me understand what is going on?

OK, I figured out an appropriate approach. I'll test it in a pre-
release of VDT 1.8.1, and it will ship early next week. It's also in
the upcoming VDT 1.10.0.

-alain
Change now made to 1.8.1m, which should be released tomorrow.