Re: [galaxy-dev] Cluster Install Path Errors

2018-01-29 Thread John Letaw
Hi Nate,

Thanks for the quick response, it gave me the lightbulb I needed.  I did the 
following:

On the cluster side, I custom installed python libraries based on the 
instructions in “Framework dependencies.”  This was placed in the Galaxy 
directory, but there would’ve been access to OS specific libraries.  Then, I 
created a vm-specific directory, and also installed libraries there via 
virtualenv.  In job_conf, I added a line to force use of the Galaxy directory 
venv.  Before starting Galaxy with the –no-create-env and –skip-wheels flags, I 
set GALAXY_VIRTUAL_ENV explicitly to look in the vm-specific venv directory 
(export GALAXY_VIRTUAL_ENV=”/galaxy/venv” && sh run.sh).  This did the trick.  
A job was successfully returned from the cluster and metadata properly set.  My 
only question would be, are any of these steps not necessary?

Thanks for your help!

From: Nate Coraor <n...@bx.psu.edu>
Date: Monday, January 29, 2018 at 7:33 AM
To: John Letaw <le...@ohsu.edu>
Cc: galaxy-dev <galaxy-dev@lists.galaxyproject.org>
Subject: Re: [galaxy-dev] Cluster Install Path Errors

Hi John,

Can you verify that your virtualenv created on the cluster is the one being 
used by jobs? It should be possible to view using a test job's script file, the 
path to which is logged at run time.

Thanks,
--nate

On Mon, Jan 29, 2018 at 1:00 AM, John Letaw 
<le...@ohsu.edu<mailto:le...@ohsu.edu>> wrote:
Hi Nate,

I tried to get this to work, but it is not getting rid of the error.  I was 
able to symlink the platform dependent lib-dynload libraries to a recognized 
directory, which removed the error telling me _hashlib was not found.  Now, I’m 
just left with:

galaxy.jobs.output_checker DEBUG 2018-01-28 21:50:36,883 Tool produced standard 
error failing job - [Could not find platform dependent libraries 
Consider setting $PYTHONHOME to [:]
]

Maybe, as Cao suggested, I should just be installing a common version in the 
shared directory between the two filesystems.  The job is correctly being 
scheduled and completes, metadata is just not written.  I’m certainly open to 
any additional ideas.

Thanks,
John

From: Nate Coraor <n...@bx.psu.edu<mailto:n...@bx.psu.edu>>
Date: Thursday, January 18, 2018 at 1:12 PM
To: Cao Tang <charlietan...@gmail.com<mailto:charlietan...@gmail.com>>
Cc: John Letaw <le...@ohsu.edu<mailto:le...@ohsu.edu>>, galaxy-dev 
<galaxy-dev@lists.galaxyproject.org<mailto:galaxy-dev@lists.galaxyproject.org>>
Subject: Re: [galaxy-dev] Cluster Install Path Errors

I think this error most commonly occurs when a virtualenv is used with a 
different python than the one it was created with. Is the cluster also running 
Ubuntu 14.04? If not, you can create a separate virtualenv for running tools 
using the instructions at:

https://docs.galaxyproject.org/en/master/admin/framework_dependencies.html#managing-dependencies-manually

Once created, your tools can use it by setting `/path/to/venv` on the destination in 
job_conf.xml

--nate

On Thu, Jan 18, 2018 at 1:50 PM, Cao Tang 
<charlietan...@gmail.com<mailto:charlietan...@gmail.com>> wrote:
You can try to install:

https://pypi.python.org/pypi/hashlib

On Thu, Jan 18, 2018 at 1:22 PM, John Letaw 
<le...@ohsu.edu<mailto:le...@ohsu.edu>> wrote:
Thanks for the response Peter.  I currently have this instance installed on a 
lustre fs, that is visible on an Ubuntu 14.04 vm.  So, there very well may be 
mismatches between directories on the VM, and those on the lustre cluster.  
This would mean the python installation on the VM needs to exactly match that 
which is on the cluster?  What else will need to match to ensure success?

Thanks,
John

On 1/18/18, 1:50 AM, "Peter Cock" 
<p.j.a.c...@googlemail.com<mailto:p.j.a.c...@googlemail.com>> wrote:

I *think* this is a problem with your copy of Python 2.7 and a
standard library (hashlib) normally present. Do you know how this
Python was installed? If it was compiled from source, then it may have
been missing a few dependencies, and thus you have ended up with
missing a few normally present Python modules.

Peter

On Wed, Jan 17, 2018 at 11:15 PM, John Letaw 
<le...@ohsu.edu<mailto:le...@ohsu.edu>> wrote:
> Hi all,
>
>
>
> I have been trying to finish up a production cluster Galaxy installation,
> and am having trouble with the below error.  In the past, when seeing
> something along these lines, I usually can adjust environmental variables
> either in startup scripts, or by including a script for Galaxy to source
> before it sends out a job.  I have tried all of these different methods, 
but
> I can’t seem to get rid of this error message in any tool invocation.  I
> currently have “embed_metadata_in_job” set to False in my job_conf.xml 
file.
> This removes a “No mod

Re: [galaxy-dev] Cluster Install Path Errors

2018-01-29 Thread Nate Coraor
Hi John,

Can you verify that your virtualenv created on the cluster is the one being
used by jobs? It should be possible to view using a test job's script file,
the path to which is logged at run time.

Thanks,
--nate

On Mon, Jan 29, 2018 at 1:00 AM, John Letaw <le...@ohsu.edu> wrote:

> Hi Nate,
>
>
>
> I tried to get this to work, but it is not getting rid of the error.  I
> was able to symlink the platform dependent lib-dynload libraries to a
> recognized directory, which removed the error telling me _hashlib was not
> found.  Now, I’m just left with:
>
>
>
> galaxy.jobs.output_checker DEBUG 2018-01-28 21:50:36,883 Tool produced
> standard error failing job - [Could not find platform dependent libraries
> 
>
> Consider setting $PYTHONHOME to [:]
>
> ]
>
>
>
> Maybe, as Cao suggested, I should just be installing a common version in
> the shared directory between the two filesystems.  The job is correctly
> being scheduled and completes, metadata is just not written.  I’m certainly
> open to any additional ideas.
>
>
>
> Thanks,
>
> John
>
>
>
> *From: *Nate Coraor <n...@bx.psu.edu>
> *Date: *Thursday, January 18, 2018 at 1:12 PM
> *To: *Cao Tang <charlietan...@gmail.com>
> *Cc: *John Letaw <le...@ohsu.edu>, galaxy-dev <galaxy-dev@lists.
> galaxyproject.org>
> *Subject: *Re: [galaxy-dev] Cluster Install Path Errors
>
>
>
> I think this error most commonly occurs when a virtualenv is used with a
> different python than the one it was created with. Is the cluster also
> running Ubuntu 14.04? If not, you can create a separate virtualenv for
> running tools using the instructions at:
>
>
>
> https://docs.galaxyproject.org/en/master/admin/framework_
> dependencies.html#managing-dependencies-manually
>
>
>
> Once created, your tools can use it by setting ` id="GALAXY_VIRTUAL_ENV">/path/to/venv` on the destination in
> job_conf.xml
>
>
>
> --nate
>
>
>
> On Thu, Jan 18, 2018 at 1:50 PM, Cao Tang <charlietan...@gmail.com> wrote:
>
> You can try to install:
>
> https://pypi.python.org/pypi/hashlib
>
>
>
> On Thu, Jan 18, 2018 at 1:22 PM, John Letaw <le...@ohsu.edu> wrote:
>
> Thanks for the response Peter.  I currently have this instance installed
> on a lustre fs, that is visible on an Ubuntu 14.04 vm.  So, there very well
> may be mismatches between directories on the VM, and those on the lustre
> cluster.  This would mean the python installation on the VM needs to
> exactly match that which is on the cluster?  What else will need to match
> to ensure success?
>
> Thanks,
> John
>
> On 1/18/18, 1:50 AM, "Peter Cock" <p.j.a.c...@googlemail.com> wrote:
>
> I *think* this is a problem with your copy of Python 2.7 and a
> standard library (hashlib) normally present. Do you know how this
> Python was installed? If it was compiled from source, then it may have
> been missing a few dependencies, and thus you have ended up with
> missing a few normally present Python modules.
>
> Peter
>
> On Wed, Jan 17, 2018 at 11:15 PM, John Letaw <le...@ohsu.edu> wrote:
> > Hi all,
> >
> >
> >
> > I have been trying to finish up a production cluster Galaxy
> installation,
> > and am having trouble with the below error.  In the past, when seeing
> > something along these lines, I usually can adjust environmental
> variables
> > either in startup scripts, or by including a script for Galaxy to
> source
> > before it sends out a job.  I have tried all of these different
> methods, but
> > I can’t seem to get rid of this error message in any tool
> invocation.  I
> > currently have “embed_metadata_in_job” set to False in my
> job_conf.xml file.
> > This removes a “No module named galaxy_ext.metadata.set_metadata”
> error, but
> > this hashlib error remains.  If I could understand a little more
> about the
> > steps that are taken when sending out a job, perhaps I could better
> diagnose
> > this?
> >
> >
> >
> > “””
> >
> > Could not find platform dependent libraries
> >
> > Consider setting $PYTHONHOME to [:]
> >
> > Traceback (most recent call last):
> >
> >   File "~/galaxydev/galaxy/tools/data_source/upload.py", line 14, in
> >
> > import tempfile
> >
> >   File "/usr/lib64/python2.7/tempfile.py", line 35, in
> >
> > from random import Random as _Random
>

Re: [galaxy-dev] Cluster Install Path Errors

2018-01-28 Thread John Letaw
Hi Nate,

I tried to get this to work, but it is not getting rid of the error.  I was 
able to symlink the platform dependent lib-dynload libraries to a recognized 
directory, which removed the error telling me _hashlib was not found.  Now, I’m 
just left with:

galaxy.jobs.output_checker DEBUG 2018-01-28 21:50:36,883 Tool produced standard 
error failing job - [Could not find platform dependent libraries 
Consider setting $PYTHONHOME to [:]
]

Maybe, as Cao suggested, I should just be installing a common version in the 
shared directory between the two filesystems.  The job is correctly being 
scheduled and completes, metadata is just not written.  I’m certainly open to 
any additional ideas.

Thanks,
John

From: Nate Coraor <n...@bx.psu.edu>
Date: Thursday, January 18, 2018 at 1:12 PM
To: Cao Tang <charlietan...@gmail.com>
Cc: John Letaw <le...@ohsu.edu>, galaxy-dev <galaxy-dev@lists.galaxyproject.org>
Subject: Re: [galaxy-dev] Cluster Install Path Errors

I think this error most commonly occurs when a virtualenv is used with a 
different python than the one it was created with. Is the cluster also running 
Ubuntu 14.04? If not, you can create a separate virtualenv for running tools 
using the instructions at:

https://docs.galaxyproject.org/en/master/admin/framework_dependencies.html#managing-dependencies-manually

Once created, your tools can use it by setting `/path/to/venv` on the destination in 
job_conf.xml

--nate

On Thu, Jan 18, 2018 at 1:50 PM, Cao Tang 
<charlietan...@gmail.com<mailto:charlietan...@gmail.com>> wrote:
You can try to install:

https://pypi.python.org/pypi/hashlib

On Thu, Jan 18, 2018 at 1:22 PM, John Letaw 
<le...@ohsu.edu<mailto:le...@ohsu.edu>> wrote:
Thanks for the response Peter.  I currently have this instance installed on a 
lustre fs, that is visible on an Ubuntu 14.04 vm.  So, there very well may be 
mismatches between directories on the VM, and those on the lustre cluster.  
This would mean the python installation on the VM needs to exactly match that 
which is on the cluster?  What else will need to match to ensure success?

Thanks,
John

On 1/18/18, 1:50 AM, "Peter Cock" 
<p.j.a.c...@googlemail.com<mailto:p.j.a.c...@googlemail.com>> wrote:

I *think* this is a problem with your copy of Python 2.7 and a
standard library (hashlib) normally present. Do you know how this
Python was installed? If it was compiled from source, then it may have
been missing a few dependencies, and thus you have ended up with
missing a few normally present Python modules.

Peter

On Wed, Jan 17, 2018 at 11:15 PM, John Letaw 
<le...@ohsu.edu<mailto:le...@ohsu.edu>> wrote:
> Hi all,
>
>
>
> I have been trying to finish up a production cluster Galaxy installation,
> and am having trouble with the below error.  In the past, when seeing
> something along these lines, I usually can adjust environmental variables
> either in startup scripts, or by including a script for Galaxy to source
> before it sends out a job.  I have tried all of these different methods, 
but
> I can’t seem to get rid of this error message in any tool invocation.  I
> currently have “embed_metadata_in_job” set to False in my job_conf.xml 
file.
> This removes a “No module named galaxy_ext.metadata.set_metadata” error, 
but
> this hashlib error remains.  If I could understand a little more about the
> steps that are taken when sending out a job, perhaps I could better 
diagnose
> this?
>
>
>
> “””
>
> Could not find platform dependent libraries
>
> Consider setting $PYTHONHOME to [:]
>
> Traceback (most recent call last):
>
>   File "~/galaxydev/galaxy/tools/data_source/upload.py", line 14, in
>
> import tempfile
>
>   File "/usr/lib64/python2.7/tempfile.py", line 35, in
>
> from random import Random as _Random
>
>  File "/usr/lib64/python2.7/random.py", line 49, in
>
> import hashlib as _hashlib
>
>   File "/usr/lib64/python2.7/hashlib.py", line 116, in
>
> import _hashlib
>
> ImportError: No module named _hashlib
>
> “””
>
>
>
> Thanks,
>
> John
>
>
> ___
> Please keep all replies on the list by using "reply all"
> in your mail client.  To manage your subscriptions to this
> and other Galaxy lists, please use the interface at:
>   https://lists.galaxyproject.org/
>
> To search Galaxy mailing lists use the unified search at:
>   http://galaxyproject.org/search/


__

Re: [galaxy-dev] Cluster Install Path Errors

2018-01-18 Thread John Letaw
Hi Nate,

Ah, I like this answer, let me see if I can make it work.  The way I currently 
have the instance set up is inside an Ubuntu 14.04 VM, that has been configured 
to accept lustre mounts.  The galaxy code is installed in a lustre directory, 
which I mainly did to avoid any issues with the cluster seeing important files. 
 I figure the installation may need to be moved to a local VM directory, with 
the Galaxy files visible in a lustre directory.  Anyways, the cluster itself is 
based on CentOS 7.  If you have any other suggestions for this type of setup, 
please let me know before I go too deep in the rabbit hole!

Cao – I can see hashlib in all of the correct places, but I will try to mess 
with the installation if the virtualenv method doesn’t help me.

Thanks so much!

From: Nate Coraor <n...@bx.psu.edu>
Date: Thursday, January 18, 2018 at 1:12 PM
To: Cao Tang <charlietan...@gmail.com>
Cc: John Letaw <le...@ohsu.edu>, galaxy-dev <galaxy-dev@lists.galaxyproject.org>
Subject: Re: [galaxy-dev] Cluster Install Path Errors

I think this error most commonly occurs when a virtualenv is used with a 
different python than the one it was created with. Is the cluster also running 
Ubuntu 14.04? If not, you can create a separate virtualenv for running tools 
using the instructions at:

https://docs.galaxyproject.org/en/master/admin/framework_dependencies.html#managing-dependencies-manually

Once created, your tools can use it by setting `/path/to/venv` on the destination in 
job_conf.xml

--nate

On Thu, Jan 18, 2018 at 1:50 PM, Cao Tang 
<charlietan...@gmail.com<mailto:charlietan...@gmail.com>> wrote:
You can try to install:

https://pypi.python.org/pypi/hashlib

On Thu, Jan 18, 2018 at 1:22 PM, John Letaw 
<le...@ohsu.edu<mailto:le...@ohsu.edu>> wrote:
Thanks for the response Peter.  I currently have this instance installed on a 
lustre fs, that is visible on an Ubuntu 14.04 vm.  So, there very well may be 
mismatches between directories on the VM, and those on the lustre cluster.  
This would mean the python installation on the VM needs to exactly match that 
which is on the cluster?  What else will need to match to ensure success?

Thanks,
John

On 1/18/18, 1:50 AM, "Peter Cock" 
<p.j.a.c...@googlemail.com<mailto:p.j.a.c...@googlemail.com>> wrote:

I *think* this is a problem with your copy of Python 2.7 and a
standard library (hashlib) normally present. Do you know how this
Python was installed? If it was compiled from source, then it may have
been missing a few dependencies, and thus you have ended up with
missing a few normally present Python modules.

Peter

On Wed, Jan 17, 2018 at 11:15 PM, John Letaw 
<le...@ohsu.edu<mailto:le...@ohsu.edu>> wrote:
> Hi all,
>
>
>
> I have been trying to finish up a production cluster Galaxy installation,
> and am having trouble with the below error.  In the past, when seeing
> something along these lines, I usually can adjust environmental variables
> either in startup scripts, or by including a script for Galaxy to source
> before it sends out a job.  I have tried all of these different methods, 
but
> I can’t seem to get rid of this error message in any tool invocation.  I
> currently have “embed_metadata_in_job” set to False in my job_conf.xml 
file.
> This removes a “No module named galaxy_ext.metadata.set_metadata” error, 
but
> this hashlib error remains.  If I could understand a little more about the
> steps that are taken when sending out a job, perhaps I could better 
diagnose
> this?
>
>
>
> “””
>
> Could not find platform dependent libraries
>
> Consider setting $PYTHONHOME to [:]
>
> Traceback (most recent call last):
>
>   File "~/galaxydev/galaxy/tools/data_source/upload.py", line 14, in
>
> import tempfile
>
>   File "/usr/lib64/python2.7/tempfile.py", line 35, in
>
> from random import Random as _Random
>
>  File "/usr/lib64/python2.7/random.py", line 49, in
>
> import hashlib as _hashlib
>
>   File "/usr/lib64/python2.7/hashlib.py", line 116, in
>
> import _hashlib
>
> ImportError: No module named _hashlib
>
> “””
>
>
>
> Thanks,
>
> John
>
>
> ___
> Please keep all replies on the list by using "reply all"
> in your mail client.  To manage your subscriptions to this
> and other Galaxy lists, please use the interface at:
>   https://lists.galaxyproject.org/
>
> To search Galaxy mailing 

Re: [galaxy-dev] Cluster Install Path Errors

2018-01-18 Thread Nate Coraor
I think this error most commonly occurs when a virtualenv is used with a
different python than the one it was created with. Is the cluster also
running Ubuntu 14.04? If not, you can create a separate virtualenv for
running tools using the instructions at:

https://docs.galaxyproject.org/en/master/admin/framework_dependencies.html#managing-dependencies-manually

Once created, your tools can use it by setting `/path/to/venv` on the destination in
job_conf.xml

--nate

On Thu, Jan 18, 2018 at 1:50 PM, Cao Tang  wrote:

> You can try to install:
>
> https://pypi.python.org/pypi/hashlib
>
> On Thu, Jan 18, 2018 at 1:22 PM, John Letaw  wrote:
>
>> Thanks for the response Peter.  I currently have this instance installed
>> on a lustre fs, that is visible on an Ubuntu 14.04 vm.  So, there very well
>> may be mismatches between directories on the VM, and those on the lustre
>> cluster.  This would mean the python installation on the VM needs to
>> exactly match that which is on the cluster?  What else will need to match
>> to ensure success?
>>
>> Thanks,
>> John
>>
>> On 1/18/18, 1:50 AM, "Peter Cock"  wrote:
>>
>> I *think* this is a problem with your copy of Python 2.7 and a
>> standard library (hashlib) normally present. Do you know how this
>> Python was installed? If it was compiled from source, then it may have
>> been missing a few dependencies, and thus you have ended up with
>> missing a few normally present Python modules.
>>
>> Peter
>>
>> On Wed, Jan 17, 2018 at 11:15 PM, John Letaw  wrote:
>> > Hi all,
>> >
>> >
>> >
>> > I have been trying to finish up a production cluster Galaxy
>> installation,
>> > and am having trouble with the below error.  In the past, when
>> seeing
>> > something along these lines, I usually can adjust environmental
>> variables
>> > either in startup scripts, or by including a script for Galaxy to
>> source
>> > before it sends out a job.  I have tried all of these different
>> methods, but
>> > I can’t seem to get rid of this error message in any tool
>> invocation.  I
>> > currently have “embed_metadata_in_job” set to False in my
>> job_conf.xml file.
>> > This removes a “No module named galaxy_ext.metadata.set_metadata”
>> error, but
>> > this hashlib error remains.  If I could understand a little more
>> about the
>> > steps that are taken when sending out a job, perhaps I could better
>> diagnose
>> > this?
>> >
>> >
>> >
>> > “””
>> >
>> > Could not find platform dependent libraries
>> >
>> > Consider setting $PYTHONHOME to [:]
>> >
>> > Traceback (most recent call last):
>> >
>> >   File "~/galaxydev/galaxy/tools/data_source/upload.py", line 14,
>> in
>> >
>> > import tempfile
>> >
>> >   File "/usr/lib64/python2.7/tempfile.py", line 35, in
>> >
>> > from random import Random as _Random
>> >
>> >  File "/usr/lib64/python2.7/random.py", line 49, in
>> >
>> > import hashlib as _hashlib
>> >
>> >   File "/usr/lib64/python2.7/hashlib.py", line 116, in
>> >
>> > import _hashlib
>> >
>> > ImportError: No module named _hashlib
>> >
>> > “””
>> >
>> >
>> >
>> > Thanks,
>> >
>> > John
>> >
>> >
>> > ___
>> > Please keep all replies on the list by using "reply all"
>> > in your mail client.  To manage your subscriptions to this
>> > and other Galaxy lists, please use the interface at:
>> >   https://lists.galaxyproject.org/
>> >
>> > To search Galaxy mailing lists use the unified search at:
>> >   http://galaxyproject.org/search/
>>
>>
>> ___
>> Please keep all replies on the list by using "reply all"
>> in your mail client.  To manage your subscriptions to this
>> and other Galaxy lists, please use the interface at:
>>   https://lists.galaxyproject.org/
>>
>> To search Galaxy mailing lists use the unified search at:
>>   http://galaxyproject.org/search/
>
>
>
> ___
> Please keep all replies on the list by using "reply all"
> in your mail client.  To manage your subscriptions to this
> and other Galaxy lists, please use the interface at:
>   https://lists.galaxyproject.org/
>
> To search Galaxy mailing lists use the unified search at:
>   http://galaxyproject.org/search/
>
___
Please keep all replies on the list by using "reply all"
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:
  https://lists.galaxyproject.org/

To search Galaxy mailing lists use the unified search at:
  http://galaxyproject.org/search/

Re: [galaxy-dev] Cluster Install Path Errors

2018-01-18 Thread Cao Tang
You can try to install:

https://pypi.python.org/pypi/hashlib

On Thu, Jan 18, 2018 at 1:22 PM, John Letaw  wrote:

> Thanks for the response Peter.  I currently have this instance installed
> on a lustre fs, that is visible on an Ubuntu 14.04 vm.  So, there very well
> may be mismatches between directories on the VM, and those on the lustre
> cluster.  This would mean the python installation on the VM needs to
> exactly match that which is on the cluster?  What else will need to match
> to ensure success?
>
> Thanks,
> John
>
> On 1/18/18, 1:50 AM, "Peter Cock"  wrote:
>
> I *think* this is a problem with your copy of Python 2.7 and a
> standard library (hashlib) normally present. Do you know how this
> Python was installed? If it was compiled from source, then it may have
> been missing a few dependencies, and thus you have ended up with
> missing a few normally present Python modules.
>
> Peter
>
> On Wed, Jan 17, 2018 at 11:15 PM, John Letaw  wrote:
> > Hi all,
> >
> >
> >
> > I have been trying to finish up a production cluster Galaxy
> installation,
> > and am having trouble with the below error.  In the past, when seeing
> > something along these lines, I usually can adjust environmental
> variables
> > either in startup scripts, or by including a script for Galaxy to
> source
> > before it sends out a job.  I have tried all of these different
> methods, but
> > I can’t seem to get rid of this error message in any tool
> invocation.  I
> > currently have “embed_metadata_in_job” set to False in my
> job_conf.xml file.
> > This removes a “No module named galaxy_ext.metadata.set_metadata”
> error, but
> > this hashlib error remains.  If I could understand a little more
> about the
> > steps that are taken when sending out a job, perhaps I could better
> diagnose
> > this?
> >
> >
> >
> > “””
> >
> > Could not find platform dependent libraries
> >
> > Consider setting $PYTHONHOME to [:]
> >
> > Traceback (most recent call last):
> >
> >   File "~/galaxydev/galaxy/tools/data_source/upload.py", line 14, in
> >
> > import tempfile
> >
> >   File "/usr/lib64/python2.7/tempfile.py", line 35, in
> >
> > from random import Random as _Random
> >
> >  File "/usr/lib64/python2.7/random.py", line 49, in
> >
> > import hashlib as _hashlib
> >
> >   File "/usr/lib64/python2.7/hashlib.py", line 116, in
> >
> > import _hashlib
> >
> > ImportError: No module named _hashlib
> >
> > “””
> >
> >
> >
> > Thanks,
> >
> > John
> >
> >
> > ___
> > Please keep all replies on the list by using "reply all"
> > in your mail client.  To manage your subscriptions to this
> > and other Galaxy lists, please use the interface at:
> >   https://lists.galaxyproject.org/
> >
> > To search Galaxy mailing lists use the unified search at:
> >   http://galaxyproject.org/search/
>
>
> ___
> Please keep all replies on the list by using "reply all"
> in your mail client.  To manage your subscriptions to this
> and other Galaxy lists, please use the interface at:
>   https://lists.galaxyproject.org/
>
> To search Galaxy mailing lists use the unified search at:
>   http://galaxyproject.org/search/
___
Please keep all replies on the list by using "reply all"
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:
  https://lists.galaxyproject.org/

To search Galaxy mailing lists use the unified search at:
  http://galaxyproject.org/search/

Re: [galaxy-dev] Cluster Install Path Errors

2018-01-18 Thread John Letaw
Thanks for the response Peter.  I currently have this instance installed on a 
lustre fs, that is visible on an Ubuntu 14.04 vm.  So, there very well may be 
mismatches between directories on the VM, and those on the lustre cluster.  
This would mean the python installation on the VM needs to exactly match that 
which is on the cluster?  What else will need to match to ensure success?

Thanks,
John

On 1/18/18, 1:50 AM, "Peter Cock"  wrote:

I *think* this is a problem with your copy of Python 2.7 and a
standard library (hashlib) normally present. Do you know how this
Python was installed? If it was compiled from source, then it may have
been missing a few dependencies, and thus you have ended up with
missing a few normally present Python modules.

Peter

On Wed, Jan 17, 2018 at 11:15 PM, John Letaw  wrote:
> Hi all,
>
>
>
> I have been trying to finish up a production cluster Galaxy installation,
> and am having trouble with the below error.  In the past, when seeing
> something along these lines, I usually can adjust environmental variables
> either in startup scripts, or by including a script for Galaxy to source
> before it sends out a job.  I have tried all of these different methods, 
but
> I can’t seem to get rid of this error message in any tool invocation.  I
> currently have “embed_metadata_in_job” set to False in my job_conf.xml 
file.
> This removes a “No module named galaxy_ext.metadata.set_metadata” error, 
but
> this hashlib error remains.  If I could understand a little more about the
> steps that are taken when sending out a job, perhaps I could better 
diagnose
> this?
>
>
>
> “””
>
> Could not find platform dependent libraries
>
> Consider setting $PYTHONHOME to [:]
>
> Traceback (most recent call last):
>
>   File "~/galaxydev/galaxy/tools/data_source/upload.py", line 14, in
>
> import tempfile
>
>   File "/usr/lib64/python2.7/tempfile.py", line 35, in
>
> from random import Random as _Random
>
>  File "/usr/lib64/python2.7/random.py", line 49, in
>
> import hashlib as _hashlib
>
>   File "/usr/lib64/python2.7/hashlib.py", line 116, in
>
> import _hashlib
>
> ImportError: No module named _hashlib
>
> “””
>
>
>
> Thanks,
>
> John
>
>
> ___
> Please keep all replies on the list by using "reply all"
> in your mail client.  To manage your subscriptions to this
> and other Galaxy lists, please use the interface at:
>   https://lists.galaxyproject.org/
>
> To search Galaxy mailing lists use the unified search at:
>   http://galaxyproject.org/search/


___
Please keep all replies on the list by using "reply all"
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:
  https://lists.galaxyproject.org/

To search Galaxy mailing lists use the unified search at:
  http://galaxyproject.org/search/

Re: [galaxy-dev] Cluster Install Path Errors

2018-01-18 Thread Peter Cock
I *think* this is a problem with your copy of Python 2.7 and a
standard library (hashlib) normally present. Do you know how this
Python was installed? If it was compiled from source, then it may have
been missing a few dependencies, and thus you have ended up with
missing a few normally present Python modules.

Peter

On Wed, Jan 17, 2018 at 11:15 PM, John Letaw  wrote:
> Hi all,
>
>
>
> I have been trying to finish up a production cluster Galaxy installation,
> and am having trouble with the below error.  In the past, when seeing
> something along these lines, I usually can adjust environmental variables
> either in startup scripts, or by including a script for Galaxy to source
> before it sends out a job.  I have tried all of these different methods, but
> I can’t seem to get rid of this error message in any tool invocation.  I
> currently have “embed_metadata_in_job” set to False in my job_conf.xml file.
> This removes a “No module named galaxy_ext.metadata.set_metadata” error, but
> this hashlib error remains.  If I could understand a little more about the
> steps that are taken when sending out a job, perhaps I could better diagnose
> this?
>
>
>
> “””
>
> Could not find platform dependent libraries
>
> Consider setting $PYTHONHOME to [:]
>
> Traceback (most recent call last):
>
>   File "~/galaxydev/galaxy/tools/data_source/upload.py", line 14, in
>
> import tempfile
>
>   File "/usr/lib64/python2.7/tempfile.py", line 35, in
>
> from random import Random as _Random
>
>  File "/usr/lib64/python2.7/random.py", line 49, in
>
> import hashlib as _hashlib
>
>   File "/usr/lib64/python2.7/hashlib.py", line 116, in
>
> import _hashlib
>
> ImportError: No module named _hashlib
>
> “””
>
>
>
> Thanks,
>
> John
>
>
> ___
> Please keep all replies on the list by using "reply all"
> in your mail client.  To manage your subscriptions to this
> and other Galaxy lists, please use the interface at:
>   https://lists.galaxyproject.org/
>
> To search Galaxy mailing lists use the unified search at:
>   http://galaxyproject.org/search/
___
Please keep all replies on the list by using "reply all"
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:
  https://lists.galaxyproject.org/

To search Galaxy mailing lists use the unified search at:
  http://galaxyproject.org/search/

[galaxy-dev] Cluster Install Path Errors

2018-01-17 Thread John Letaw
Hi all,

I have been trying to finish up a production cluster Galaxy installation, and 
am having trouble with the below error.  In the past, when seeing something 
along these lines, I usually can adjust environmental variables either in 
startup scripts, or by including a script for Galaxy to source before it sends 
out a job.  I have tried all of these different methods, but I can’t seem to 
get rid of this error message in any tool invocation.  I currently have 
“embed_metadata_in_job” set to False in my job_conf.xml file.  This removes a 
“No module named galaxy_ext.metadata.set_metadata” error, but this hashlib 
error remains.  If I could understand a little more about the steps that are 
taken when sending out a job, perhaps I could better diagnose this?

“””
Could not find platform dependent libraries
Consider setting $PYTHONHOME to [:]
Traceback (most recent call last):
  File "~/galaxydev/galaxy/tools/data_source/upload.py", line 14, in
import tempfile
  File "/usr/lib64/python2.7/tempfile.py", line 35, in
from random import Random as _Random
 File "/usr/lib64/python2.7/random.py", line 49, in
import hashlib as _hashlib
  File "/usr/lib64/python2.7/hashlib.py", line 116, in
import _hashlib
ImportError: No module named _hashlib
“””

Thanks,
John
___
Please keep all replies on the list by using "reply all"
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:
  https://lists.galaxyproject.org/

To search Galaxy mailing lists use the unified search at:
  http://galaxyproject.org/search/