Re: [galaxy-dev] egg distribution error when running galaxy-central
Hi Nate all, I see - enthought changes the default python version, and virtualenv was giving me a python version based on the version I used to run virtualenv. If I run /usr/bin/python virtualenv.py galaxy_central_syspython . galaxy_central_syspython/bin/activate and then pull galaxy-central and run it, I don't get any egg errors, either the build-by-hand ones or the more serious error that stopped me originally. Thanks! Clare On 22 August 2012 01:26, Nate Coraor n...@bx.psu.edu wrote: Hi Clare, If you use the system python, or a build from python.org, you should be fine. It's Enthought python, which is only built for a single architecture, that's the reason for having to do so much manual egg building. --nate On Aug 19, 2012, at 7:36 AM, Tomithy Too wrote: Hi Clare, I ran into the same problem as well when I upgraded my galaxy-central version. I am running Mac Os10.6.8 What I did to get use the command $ pip install fabric It manually fetches the latest version of fabric from pip (http://www.pip-installer.org/en/latest/index.html) which is a package manager from python, also its dependencies: ssh and pycrypto, which are the components causing the problem. I think it might be due to an erroneous version of the egg hosted on galaxy. Works fine after that for me. Cheers Tomithy On Wed, Aug 15, 2012 at 10:55 AM, Clare Sloggett s...@unimelb.edu.au wrote: Hi Scott, Thanks very much for this! virtualenv is ok I think: clare$ echo $PATH /Users/clare/galaxy/galaxy_central_env/bin: . which is where I set up my environment. I'm not using anything in particular outside Enthought, that I can think of. Enthought packages up a whole lot of things including scipy. The strange thing is that galaxy-dist runs but galaxy-central doesn't. So, I was hoping it would actually be a temporary bug in the egg distribution, but it sounds like the problem really is my environment. I don't understand how Enthought can be causing problems that virtualenv can't work around, but I've never really understood how python is structured in OSX! So I think it's probably worth me going through the effort of setting up a working environment in an ubuntu VM rather than running it on my Mac - I don't want to be asking you to pull code changes from an environment that's unusual. I'm setting it up in VirtualBox ubuntu now (which has python 2.7.1). So far I've pulled the code into the vm and run it, without virtualenv, and it gives none of the errors I see on the Mac. My plan is to both share the drive containing galaxy-central and share the network so that I can do both the editing and the browsing on my host machine, but if there are better ways advice is welcome! Thanks, Clare On 2 August 2012 07:26, Scott McManus scottmcma...@gatech.edu wrote: I haven't been able to reproduce this yet with the instructions you gave, but I'm not using the same environment. Can you give me an idea of what tools you're using outside of SciPy/NumPy/Enthought stuff? There is the possibility that the virtualenv.py script isn't being sourced correctly. We can check if it's actually using the correct environment by calling echo $PATH and checking that the path is pointing to the virtual environment. For example, I installed virtualenv stuff under /home/smcmanus/clare/galaxy_env/bin, and I got: (galaxy_env)$ echo $PATH /home/smcmanus/clare/galaxy_env/bin:/usr/local/bin:other stuff deleted -Scott - Original Message - Hi all, I'm trying to run galaxy-central on my laptop in order to play around with some changes, and I'm having trouble getting it to run. I can run galaxy-dist without problems and have been working with that (so its eggs are all installed already), but now I want to create a pull request so want to run galaxy-dist. I'm not trying to install any extra tools or data, just the code. I'm running on OSX 10.7.4 and using virtualenv. I have Enthought installed, and I assume I will be using its version of python by default. The default python seems to be 2.7.3. I'm using the same virtualenv environment for galaxy-dist and galaxy-central (though it doesn't seem to matter if I give galaxy-central its own environment, I see the same error). So the steps were: - create a virtualenv environment and activate it - get galaxy-dist and call run.sh - it asked me to build quite a lot of dependencies myself, which was just a matter of running the requested commands, and then it worked with no problems. - shut down galaxy-dist, and in another directory, get galaxy-central and call run.sh. I think it asked me to build a couple of dependencies, but then it gives up with the following: (galaxy_env)Clares-MacBook-Pro:galaxy-central clare$ sh run.sh --reload Some eggs are out of date, attempting to fetch... Warning: MarkupSafe (a dependent egg of Mako) cannot be fetched Warning: pycrypto (a
[galaxy-dev] Running a Java JDBC program from galaxy
Hi, I would like to run a Java program that accepts a VCF file from Galaxy and uses a JDBC connection to a postgreSQL database to do some analysis. The program should procude an HTML table that is then displayed in the Galaxy browser window. We have a local Galaxy server, and I have added my program to it using a configuration file. When I start the program via the framework, it just hangs, and runs forever (the command line version finishes in a few seconds). I am relatively new to Galaxy and have not been able to find out how to trouble shoot this in the documentation. Some questions: 1) The tables in the postgreSQL database have been set to GRANT SELECT TO PUBLIC, and the Java program is connecting to the database with the name and password of the owner of the database. Are there any other permissions issues that result from the Galaxy framework? 2) Is there some way of following program execution from a shell to see what Galaxy is doing? 3) Any other ideas? thanks Peter PD Dr. med. Peter N. Robinson, MSc. Institut für Medizinische Genetik und Humangenetik Charité - Universitätsmedizin Berlin Augustenburger Platz 1 13353 Berlin Germany +4930 450566006 Mobile: 0160 93769872 peter.robin...@charite.de http://compbio.charite.de http://www.human-phenotype-ontology.org Introduction to Bio-Ontologies: http://www.crcpress.com/product/isbn/9781439836651 ___ 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: http://lists.bx.psu.edu/
[galaxy-dev] Using the tools API
Hi guys,
The Tools API is currently working for me from galaxy-central, but I'm
not sure how to correctly run a tool. Are there any example scripts,
as there are for some other parts of the API? Specifically I want to
find out what the expected payload fields are when I post to CREATE to
run a tool.
Some of the fields are clear to me just from the api/tools.py code
(e.g. 'tool_id') but others are not (e.g. how the input datasets and
parameters are specified).
A separate question:
How do we specify Advanced or conditional-dependent fields for a
tool? Some of these fields are necessary to run the tool at all.
For instance, on my system, calling
http://localhost:8080/api/tools/tophat?key=
returns
{
description: Find splice junctions using RNA-seq data,
id: tophat,
inputs: [
{
html: %3Cselect%20name%3D%22input1%22%3E%0A%3C/select%3E,
label: RNA-Seq FASTQ file,
name: input1,
type: data
},
{
label: Conditional (refGenomeSource),
name: refGenomeSource
},
{
label: Conditional (singlePaired),
name: singlePaired
}
],
name: Tophat for Illumina,
version: 1.5.0
}
This is obviously only some of the inputs you see in the UI. I think
that all the Advanced fields are missing, and more importantly, any
input which is dependent on a conditional is missing. So the
refGenomeSource conditional is there, but the actual reference genome
field is not. The type of the reference genome field also presumably
depends on which value is supplied for the referenceGenomeSource
conditional.
Is there currently a way to specify (or see) these missing fields?
Thanks,
Clare
--
Clare Sloggett
Research Fellow / Bioinformatician
Life Sciences Computation Centre
Victorian Life Sciences Computation Initiative
University of Melbourne, Parkville Campus
187 Grattan Street, Carlton, Melbourne
Victoria 3010, Australia
Ph: 03 903 53357 M: 0414 854 759
___
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:
http://lists.bx.psu.edu/
[galaxy-dev] So I think I fixed a bug.
Hi All, Today I found a bug relating to the file permissions in composite datatypes. When the extrafiles directory was created and the server was running through apache, the permission did not allow a galaxy user to download by following the HTML link. Found it was related to meta data files not using the os.chmod function to set the permissions of the user data in upload.py. Added that line of code and it works and the file permissions match that of other files in the database. Somehelp with submitting a patch would be welcome ( although one line patch it would be helpful to me.) Cheers James Boocock ___ 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: http://lists.bx.psu.edu/
Re: [galaxy-dev] So I think I fixed a bug.
For a simple patch like yours, just pasting and sending your diff to the list works well: %hg diff ... For bigger patches/enhancements, a bitbucket fork + pull request is highly encouraged. Best, J. On Aug 23, 2012, at 4:47 AM, James wrote: Hi All, Today I found a bug relating to the file permissions in composite datatypes. When the extrafiles directory was created and the server was running through apache, the permission did not allow a galaxy user to download by following the HTML link. Found it was related to meta data files not using the os.chmod function to set the permissions of the user data in upload.py. Added that line of code and it works and the file permissions match that of other files in the database. Somehelp with submitting a patch would be welcome ( although one line patch it would be helpful to me.) Cheers James Boocock ___ 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: http://lists.bx.psu.edu/ ___ 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: http://lists.bx.psu.edu/
Re: [galaxy-dev] Using the tools API
Unfortunately, the tools API isn't at all complete right now. The tools API was
driven by Trackster/Sweepster needs, so rerunning tools works well but running
tools from scratch doesn't.
Practically, this means that the things you want to do, e.g.
*view tool parameters;
*set tool input datasets;
are not yet supported.
As always, community contributions are welcome and encouraged.
Best,
J.
On Aug 23, 2012, at 4:10 AM, Clare Sloggett wrote:
Hi guys,
The Tools API is currently working for me from galaxy-central, but I'm
not sure how to correctly run a tool. Are there any example scripts,
as there are for some other parts of the API? Specifically I want to
find out what the expected payload fields are when I post to CREATE to
run a tool.
Some of the fields are clear to me just from the api/tools.py code
(e.g. 'tool_id') but others are not (e.g. how the input datasets and
parameters are specified).
A separate question:
How do we specify Advanced or conditional-dependent fields for a
tool? Some of these fields are necessary to run the tool at all.
For instance, on my system, calling
http://localhost:8080/api/tools/tophat?key=
returns
{
description: Find splice junctions using RNA-seq data,
id: tophat,
inputs: [
{
html: %3Cselect%20name%3D%22input1%22%3E%0A%3C/select%3E,
label: RNA-Seq FASTQ file,
name: input1,
type: data
},
{
label: Conditional (refGenomeSource),
name: refGenomeSource
},
{
label: Conditional (singlePaired),
name: singlePaired
}
],
name: Tophat for Illumina,
version: 1.5.0
}
This is obviously only some of the inputs you see in the UI. I think
that all the Advanced fields are missing, and more importantly, any
input which is dependent on a conditional is missing. So the
refGenomeSource conditional is there, but the actual reference genome
field is not. The type of the reference genome field also presumably
depends on which value is supplied for the referenceGenomeSource
conditional.
Is there currently a way to specify (or see) these missing fields?
Thanks,
Clare
--
Clare Sloggett
Research Fellow / Bioinformatician
Life Sciences Computation Centre
Victorian Life Sciences Computation Initiative
University of Melbourne, Parkville Campus
187 Grattan Street, Carlton, Melbourne
Victoria 3010, Australia
Ph: 03 903 53357 M: 0414 854 759
___
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:
http://lists.bx.psu.edu/
___
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:
http://lists.bx.psu.edu/
[galaxy-dev] Declaring dependencies on file format ToolShed entries
Dear all, Is there any way for a Tool Shed bundle (or individual tool) to declare a dependency on another Tool Shed bundle (and ideally a minimum version) which provides a datatype? For example, the 'emboss_5' suite depends on the 'emboss_datatypes' entry. Likewise the ncbi_blast_plus suite depends on 'blast_datatypes' to define the 'blastxml' format (and soon nucleotide and protein BLAST databases). As a specific case, I'd like to update my 'blast2go' wrapper to say it now also depends on blast_datatypes because it uses the 'blastxml' format. Similarly some of my sequence filtering/selection tools could be expanded to handle other formats like 'genbank', which is defined in the 'emboss_datatypes' repository. Regards, Peter ___ 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: http://lists.bx.psu.edu/
Re: [galaxy-dev] So I think I fixed a bug.
Hi All, diff -r ba56d4746f7a tools/data_source/upload.py --- a/tools/data_source/upload.pyFri Aug 03 13:31:48 2012 -0400 +++ b/tools/data_source/upload.pyFri Aug 24 01:26:36 2012 +1200 @@ -357,6 +357,7 @@ else: sniff.convert_newlines( dp ) shutil.move( dp, os.path.join( files_path, name ) ) +os.chmod(files_path +/+name, 0644) # Move the dataset to its real path shutil.move( dataset.primary_file, output_path ) # Write the job info Fixes permissions not been created for filenames correctly so an apache instance can access the extra files. Cheers James. Research Assistant Biochemistry Department University of Otago New Zealand ___ 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: http://lists.bx.psu.edu/
[galaxy-dev] patch contribution (was Re: So I think I fixed a bug.)
Maybe I'm just doing it wrong… but I find it unusually difficult to put together a coherent pull request without doing a dedicated repo clone. maybe somebody who knows a good way to submit pull requests could populate this wiki page? http://wiki.g2.bx.psu.edu/Develop/Mercurial brad On Aug 23, 2012, at 8:55 AM, Jeremy Goecks jeremy.goe...@emory.edu wrote: For a simple patch like yours, just pasting and sending your diff to the list works well: %hg diff ... For bigger patches/enhancements, a bitbucket fork + pull request is highly encouraged. Best, J. On Aug 23, 2012, at 4:47 AM, James wrote: Hi All, Today I found a bug relating to the file permissions in composite datatypes. When the extrafiles directory was created and the server was running through apache, the permission did not allow a galaxy user to download by following the HTML link. Found it was related to meta data files not using the os.chmod function to set the permissions of the user data in upload.py. Added that line of code and it works and the file permissions match that of other files in the database. Somehelp with submitting a patch would be welcome ( although one line patch it would be helpful to me.) Cheers James Boocock ___ 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: http://lists.bx.psu.edu/ ___ 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: http://lists.bx.psu.edu/ -- Brad Langhorst langho...@neb.com 978-380-7564 ___ 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: http://lists.bx.psu.edu/
[galaxy-dev] ToolShed README files, was: Blast2GO local instance
On Tue, Apr 3, 2012 at 12:16 PM, Greg Von Kuster g...@bx.psu.edu wrote: On Apr 3, 2012, at 6:07 AM, Peter Cock wrote: On Mon, Apr 2, 2012 at 6:41 PM, Greg Von Kuster g...@bx.psu.edu wrote: On Mar 24, 2012, at 7:30 AM, Peter Cock wrote: Have you seen the README file that comes with the Blast2GO wrapper? Perhaps the 'install from toolshed' could be tweaked to make this kind of documentation more visible... If you are installing a single repository that contains a file named one of (case is ignored) readme, readme.txt, read_me, read_me.txt, the contents of the file will be displayed on the tool panel section selection page. An example using the antismash repository on the main tool shed is below. This new feature is available in change set revision 6945:5ea04ccb61e8, which is currently running on the Galaxy tool shed and our central development repository. It will be available in the next Galaxy distribution. Great. In this case I've actually called the file blast2go.txt (to match the use of blast2go.xml and blast2go.py). I didn't want to use a generic name like README since there could be other tools installed in the same folder (this predates the auto-install system). Is this naming pattern common used enough to justify including in the Galaxy Tool Shed code for spotting a README file? Since the read me file contains instructions for installing the tools in the repository, would it be better to assume only 1 installation file that includes different instructions per contained tool if necessary? If multiple read me files are allowed per repository, they would all have to be merged together with the entire content displayed on the tool panel section selection screen anyway, so allowing only a single file would be better. The read me in your blast2go repository is named blast2go.txt, so I suppose we could expand the read me file name list to include repository name.txt. I'll do this. Hi Greg, Could you include repository name.txt on the list of README filenames looked for by the ToolShed as you said please? I've just checked and it isn't working at the moment. e.g. blast2go, seq_rename, clinod, venn_list, ... - in fact most of my tools :( Thanks, Peter ___ 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: http://lists.bx.psu.edu/
Re: [galaxy-dev] Using the tools API
Hi Jeremy,
Thanks for the info!
I am confused though because the code in tools.py was what was making
me think I could run a tool with specified inputs. ie I was looking at
def create( ... )
# Set up inputs.
inputs = payload[ 'inputs' ]
params = util.Params( inputs, sanitize = False )
template, vars = tool.handle_input( trans, params.__dict__ )
I think that handle_input() executes the tool? Also, separately there
is a method called _run_tool() (although unlike _rerun_tool() I can't
see anything that calls it).
So, I thought from looking at the surface, that the tool-running code
was there and that I just didn't know what data structure to pass into
payload['inputs'] . Is it not doing what I think?
Thanks,
Clare
On 23 August 2012 23:00, Jeremy Goecks jeremy.goe...@emory.edu wrote:
Unfortunately, the tools API isn't at all complete right now. The tools API
was driven by Trackster/Sweepster needs, so rerunning tools works well but
running tools from scratch doesn't.
Practically, this means that the things you want to do, e.g.
*view tool parameters;
*set tool input datasets;
are not yet supported.
As always, community contributions are welcome and encouraged.
Best,
J.
On Aug 23, 2012, at 4:10 AM, Clare Sloggett wrote:
Hi guys,
The Tools API is currently working for me from galaxy-central, but I'm
not sure how to correctly run a tool. Are there any example scripts,
as there are for some other parts of the API? Specifically I want to
find out what the expected payload fields are when I post to CREATE to
run a tool.
Some of the fields are clear to me just from the api/tools.py code
(e.g. 'tool_id') but others are not (e.g. how the input datasets and
parameters are specified).
A separate question:
How do we specify Advanced or conditional-dependent fields for a
tool? Some of these fields are necessary to run the tool at all.
For instance, on my system, calling
http://localhost:8080/api/tools/tophat?key=
returns
{
description: Find splice junctions using RNA-seq data,
id: tophat,
inputs: [
{
html: %3Cselect%20name%3D%22input1%22%3E%0A%3C/select%3E,
label: RNA-Seq FASTQ file,
name: input1,
type: data
},
{
label: Conditional (refGenomeSource),
name: refGenomeSource
},
{
label: Conditional (singlePaired),
name: singlePaired
}
],
name: Tophat for Illumina,
version: 1.5.0
}
This is obviously only some of the inputs you see in the UI. I think
that all the Advanced fields are missing, and more importantly, any
input which is dependent on a conditional is missing. So the
refGenomeSource conditional is there, but the actual reference genome
field is not. The type of the reference genome field also presumably
depends on which value is supplied for the referenceGenomeSource
conditional.
Is there currently a way to specify (or see) these missing fields?
Thanks,
Clare
--
Clare Sloggett
Research Fellow / Bioinformatician
Life Sciences Computation Centre
Victorian Life Sciences Computation Initiative
University of Melbourne, Parkville Campus
187 Grattan Street, Carlton, Melbourne
Victoria 3010, Australia
Ph: 03 903 53357 M: 0414 854 759
___
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:
http://lists.bx.psu.edu/
--
Clare Sloggett
Research Fellow / Bioinformatician
Life Sciences Computation Centre
Victorian Life Sciences Computation Initiative
University of Melbourne, Parkville Campus
187 Grattan Street, Carlton, Melbourne
Victoria 3010, Australia
Ph: 03 903 53357 M: 0414 854 759
___
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:
http://lists.bx.psu.edu/
Re: [galaxy-dev] patch contribution (was Re: So I think I fixed a bug.)
I don't know that difficult is the right word, I would call the process heavy handed and time consuming, especially relative to similar git workflows. I have heard the Galaxy developers say on multiple occasions the prefer pull requests coming using a dedicated clone though and this makes a lot of sense because branches stick around forever in mercurial. So I now use dedicated repositories for each of my pull requests. I am still trying to optimize my workflow, but here is a high level overview of my current process. We have a local version of Galaxy (lets call it msi-galaxy), if we want to push changes back I generally create a dedicated clone of galaxy-central on bitbucket for this change (say galaxy-central-feature1) and then export the desired revision/revisions as a patch from our local branch and import it in my feature clone. % cd msi-galaxy % hg export -r rev1 -r rev2 /tmp/feature1.patch % cd .. % hg clone ssh://h...@bitbucket.org/jmchilton/galaxy-central-feature1 % cd galaxy-central-feature1 % hg import /tmp/feature1.patch % hg push Create pull request. Other tricks I have learned: Use ssh keys for bitbucket interactions instead of https, it seems considerably faster. You can add --no-commit to the import and then manually commit. This can let you map multiple changesets from your local branch to the feature clone (a poor man's rebasing I guess). The longest part of the process is the original clone down of the feature clones. So I have just started reusing old clones for this. - Rename galaxy-central-old-feature to galaxy-central-new-feature on bitbucket. - % cd galaxy-central-old-feature - % hg pull ssh://h...@bitbucket.org/galaxy/galaxy-central # catch up with galaxy-central - Make changes - % hg push ssh://h...@bitbucket.org/jmchilton/galaxy-central-new-feature - Create pull request. The downside of this cheat is that previously accept pull requests now have source repository names associated with them in bitbucket, like this https://bitbucket.org/galaxy/galaxy-central/pull-request/44/allow-usage-of-directory-of-configuration. -John John Chilton Senior Software Developer University of Minnesota Supercomputing Institute Office: 612-625-0917 Cell: 612-226-9223 On Thu, Aug 23, 2012 at 8:29 AM, Langhorst, Brad langho...@neb.com wrote: Maybe I'm just doing it wrong… but I find it unusually difficult to put together a coherent pull request without doing a dedicated repo clone. maybe somebody who knows a good way to submit pull requests could populate this wiki page? http://wiki.g2.bx.psu.edu/Develop/Mercurial brad On Aug 23, 2012, at 8:55 AM, Jeremy Goecks jeremy.goe...@emory.edu wrote: For a simple patch like yours, just pasting and sending your diff to the list works well: %hg diff ... For bigger patches/enhancements, a bitbucket fork + pull request is highly encouraged. Best, J. On Aug 23, 2012, at 4:47 AM, James wrote: Hi All, Today I found a bug relating to the file permissions in composite datatypes. When the extrafiles directory was created and the server was running through apache, the permission did not allow a galaxy user to download by following the HTML link. Found it was related to meta data files not using the os.chmod function to set the permissions of the user data in upload.py. Added that line of code and it works and the file permissions match that of other files in the database. Somehelp with submitting a patch would be welcome ( although one line patch it would be helpful to me.) Cheers James Boocock ___ 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: http://lists.bx.psu.edu/ ___ 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: http://lists.bx.psu.edu/ -- Brad Langhorst langho...@neb.com 978-380-7564 ___ 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: http://lists.bx.psu.edu/ ___ 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: http://lists.bx.psu.edu/
[galaxy-dev] Tool development without a local Tool Shed?
Dear all, Until recently I'd not needed to define new datatypes while developing tools for Galaxy - instead using (and sometimes modifying) existing datatypes in situ. I have been manually 'installing' my in-development tools by added their XML files to tool_conf.xml - and this has worked fine to date. However, I would now like to experiment with defining or modifying datatypes which would eventually be defined via a datatypes_conf.xml file in a ToolShed entry. My impression from reading the latest wiki documentation on http://wiki.g2.bx.psu.edu/Tool%20Shed is that I will have to install my own local tool shed. Is there a simpler alternative? e.g. Can I add the new datatypes_conf.xml file(s) to a configuration entry instead? Thanks, Peter ___ 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: http://lists.bx.psu.edu/
Re: [galaxy-dev] Using the tools API
I think that handle_input() executes the tool? That's the intention and it should work but it hasn't been tested. Also, separately there is a method called _run_tool() (although unlike _rerun_tool() I can't see anything that calls it). Looks like _run_tool is almost a copy of what's in create(). This is probably legacy code from refactoring that hasn't been cleaned up yet. So, I thought from looking at the surface, that the tool-running code was there and that I just didn't know what data structure to pass into payload['inputs'] . Is it not doing what I think? I think your inference is correct, but, yes, there's the problem of specifying the tool input data structure. Tool inputs are specified as dictionaries (often with nested dictionaries for things like conditionals), so you could construct an appropriate input dictionary and could (likely) run a tool. However, there's no help in the API right now to help you construct an appropriate dictionary for a tool; this is the big missing piece in the tools API. Best, J. ___ 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: http://lists.bx.psu.edu/
Re: [galaxy-dev] Installing Galaxy and Hooking into a SGE Cluster
(Moving to Galaxy-dev, seems more appropriate). John Jones wrote, On 08/23/2012 05:29 PM: His original question was about getting Galaxy to recognise LDAP authentication and personal storage space rather than shared storage space as is usual with Galaxy. Licensing only came into it because Greg wanted LDAP authentication to track individual user usage (for billing) and I questioned the legality of billing for the software used by Galaxy, as I'm sure some components have a non-commercial usage licence clause. 1. Technically (billing on an SGE cluster): There's a script in ./contrib called collect_sge_job_timings.sh . details are here: http://dev.list.galaxyproject.org/Detailed-SGE-timing-information-about-galaxy-jobs-tt4140860.html Assuming you're using PostgreSQL + SGE, it will give you what you want (break-down of SGE jobs timings and Galaxy users). With little adaptation, you can use it to exact SGE JobID and Galaxy Tool-ID / user ID. If you want to extract it directly from the galaxy database, then the following SQL will get you started: === select email as user, tool_id as tool, job_runner_external_id as SGE_ID from job, galaxy_user where job.user_id = galaxy_user.id and job_runner_name like 'drmaa%' ; === job_runner_external_ID will be the SGE-ID, and once you have the list (per each galaxy user), you can use qacct to get the information for the job, then calculate the charges. 2. Legally: IANAL, but to the best of my (limited) understanding: 1. Galaxy itself (server code, etc.) - completely legal to run it commercially, even charge money for it - it is licensed as a BSD/MIT style license. 2. Individual tools: if the tools are GPL'd (e.g. bowtie, tophat, bwa, cufflinks) or BSD/MIT - completely legal to run them commercially, and even charge money for them. if the tools use any special license that restrict commercial use (commonly stated as free for personal, academic, non-commercial use, e.g. Jim Kent's UCSC Genome Browser tools) - then you can't use them in your commercial company without buying a special license (not even internally). It's really not complicated at all, and most (if not all) tools that you compile from source to install them will have a file called license or copying that will tell you what is the license. If the tools didn't come with a source code, they are probably not free/open-source for commercial use (e.g. - novoalign). 3. Morally: Anyone who thinks of free/open-source as charity is missing the point. There is no charity, and it's perfectly legal, moral, and even recommended to charge money when offering services that are based on free/open-source tools - the requirement (when using GPL) is to give the source code to users when they ask for it (and some other complications, don't want to start a flame war here) - so if they don't want to pay $1,000 for your service - the are more than welcomed to buy their own cluster and storage and servers and run the program themselves - that is the whole point of free/open source. There is not charity. When people write (and publish) software - they explicitly decide upon the license they prefer, and they should know what are the affects of the license. For example, the Galaxy team released Galaxy under a permissive BSD/MIT style license, so they were completely aware of the fact that not only Galaxy can be incorporated into a commercial product, the license doesn't even require the commercial company to release any code changes they make to Galaxy. It's a conscious decision, not an after-thought, and not charity. (end of my rambling...) -gordon ___ 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: http://lists.bx.psu.edu/
