Re: [galaxy-dev] What is the correct place under Galaxy for a database that's created by a tool?

2014-06-17 Thread Björn Grüning
Hi Melissa, Am 17.06.2014 01:07, schrieb Melissa Cline: Hi folks, Hopefully this is a quick question. I'm working on a set of tools that will fire off a VM from within Galaxy and will then communicate with the VM. The VM will create a local database. Are we talking here about a local

Re: [galaxy-dev] Using Mesos to Enable distributed computing under Galaxy?

2014-06-17 Thread Kyle Ellrott
Glad to see someone else is playing around with Mesos. I have a mesos branch that is getting a little long in the tooth. I'd like to get a straight job runner (non-LWR, with a shared file system) running under mesos for Galaxy before I submit that work for a pull request. The hackathon is only 12

Re: [galaxy-dev] R bioconductor dependencies when creating toolshed installation

2014-06-17 Thread Stef van Lieshout
Say option 3 is the way to go, would you say every new version of an R package should be wrapped in a new galaxy package (and give them names like matrixStats_0_10_0) or create one package (matrixStats) and update that one if a new version is worth an update. In the first way there would be an

[galaxy-dev] R version 3.1.0

2014-06-17 Thread Stef van Lieshout
Any plans to create a R 3.1.0 repository? Thanks, Stef ___ 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:

Re: [galaxy-dev] R bioconductor dependencies when creating toolshed installation

2014-06-17 Thread Björn Grüning
Hi Stef, for R packages we have a special installation routine that will (hapefully) make your life easier. I'm running into some difficulties on how to setup the installation procedure for a galaxy tool which executes an R script and has certain dependencies (mainly bioconductor packages).

Re: [galaxy-dev] R bioconductor dependencies when creating toolshed installation

2014-06-17 Thread Björn Grüning
Hi Stef, fortunately it is way easier than that. Please have a look at the setup_r_environment installation routine :) Cheers, Bjoern Am 17.06.2014 11:07, schrieb Stef van Lieshout: Say option 3 is the way to go, would you say every new version of an R package should be wrapped in a new

Re: [galaxy-dev] R bioconductor dependencies when creating toolshed installation

2014-06-17 Thread Stef van Lieshout
Hi Bjoern, That looks much better indeed ;) The only problem I still have then is that I need R 3.1.0 for a bioconductor 2.14 package (have send a new mailing list msg for that). Looking at the xml of other versions it's not something I will easily do myself. What will happen if I do not specify

Re: [galaxy-dev] R bioconductor dependencies when creating toolshed installation

2014-06-17 Thread Björn Grüning
Hi Stef, Am 17.06.2014 15:40, schrieb Stef van Lieshout: Hi Bjoern, That looks much better indeed ;) The only problem I still have then is that I need R 3.1.0 for a bioconductor 2.14 package (have send a new mailing list msg for that). Looking at the xml of other versions it's not something I

Re: [galaxy-dev] R bioconductor dependencies when creating toolshed installation

2014-06-17 Thread Stef van Lieshout
Bjoern and Dave, That sounds great. Of course my next question will be how much is a little bit ;) It just that I have to move on for now and make things at least work, so I might try it with using the default R instance now, but as soon as a 3.1.0 package is out I will definitely pick it up!

Re: [galaxy-dev] Per-tool configuration

2014-06-17 Thread Jan Kanis
Too bad there aren't any really good options. I will use the environment variable approach for the query size limit. For the gene bank links I guess modifying the .loc file is the least bad way. Maybe it can be merged into galaxy_blast, that would at least solve the interoperability problems.

Re: [galaxy-dev] What is the correct place under Galaxy for a database that's created by a tool?

2014-06-17 Thread Melissa Cline
Good thing to clarify: this is a tool-specific database, created by tools that are running inside Galaxy but that should persist after the individual tools are done with their execution. On Mon, Jun 16, 2014 at 11:23 PM, Björn Grüning bjoern.gruen...@gmail.com wrote: Hi Melissa, Am

Re: [galaxy-dev] What is the correct place under Galaxy for a database that's created by a tool?

2014-06-17 Thread Björn Grüning
Hi, Am 17.06.2014 21:25, schrieb Melissa Cline: Good thing to clarify: this is a tool-specific database, created by tools that are running inside Galaxy but that should persist after the individual tools are done with their execution. Should it persist as output data or forever even if I

Re: [galaxy-dev] Per-tool configuration

2014-06-17 Thread Peter Cock
On Tue, Jun 17, 2014 at 4:57 PM, Jan Kanis jan.c...@jankanis.nl wrote: Too bad there aren't any really good options. I will use the environment variable approach for the query size limit. Are you using the optional job splitting (parallelism) feature in Galaxy? That seems to be me to be a good

Re: [galaxy-dev] What is the correct place under Galaxy for a database that's created by a tool?

2014-06-17 Thread Melissa Cline
Hi Björn, The database should persist forever, even if the workflow is restarted. I'm not sure about the distinction between forever and output data, but the database should remain in place until the user takes specific action to make it go away. If you reload a tool, it will reload/extend the

Re: [galaxy-dev] Per-tool configuration

2014-06-17 Thread John Chilton
On Tue, Jun 17, 2014 at 2:55 PM, Peter Cock p.j.a.c...@googlemail.com wrote: On Tue, Jun 17, 2014 at 4:57 PM, Jan Kanis jan.c...@jankanis.nl wrote: Too bad there aren't any really good options. I will use the environment variable approach for the query size limit. Are you using the optional

Re: [galaxy-dev] Import of Capsules failing on local toolshed instance

2014-06-17 Thread Will Holtz
It looks like Dave fixed this issue in 4c58aa19a3d7. Thank you! However I am still having import issues. I am now getting the message: Archive of repository package_bowtie_0_12_7 owned by devteam Import failed: repository owner devteam does not have an account in this Tool Shed. This is on a

[galaxy-dev] Postgresql database time wrong...

2014-06-17 Thread Neil.Burdett
Hi I have quite a strange issue. I have a local install of Galaxy setup. When I type 'date' on my Ubuntu machine I get something like: Wed Jun 18 09:25:22 EST 2014 When i then execute a job and look in the database at the create_time i.e. # select create_time from job order by create_time;

Re: [galaxy-dev] Postgresql database time wrong...

2014-06-17 Thread Will Holtz
Postgres generally stores datatime fields in GMT, and then translates them to the local time zone when generating a query. Check the TimeZone variable in your postgres.conf. http://www.postgresql.org/docs/9.3/static/datatype-datetime.html#DATATYPE-TIMEZONES -Will On Tue, Jun 17, 2014 at 4:29

Re: [galaxy-dev] Import of Capsules failing on local toolshed instance

2014-06-17 Thread Greg Von Kuster
Hello Will, On Jun 17, 2014, at 6:06 PM, Will Holtz who...@lygos.com wrote: It looks like Dave fixed this issue in 4c58aa19a3d7. Thank you! However I am still having import issues. I am now getting the message: Archive of repository package_bowtie_0_12_7 owned by devteam Import failed:

Re: [galaxy-dev] Postgresql database time wrong...

2014-06-17 Thread Neil.Burdett
Thanks, but looking at /etc/postgresql/9.1/main/postgresql.conf i have the following: #timezone = '(defaults to server environment setting)' #timezone_abbreviations = 'Default' # Select the set of available time zone # abbreviations. Currently, there