Hi John,
No need to apologise!
This isn't really a priority for me as I can fix it with ACLs. Using a lot of
those lately - so another few won't hurt :-)
DT
-Original Message-
From: John Chilton [mailto:jmchil...@gmail.com]
Sent: Tuesday, November 17, 2015 2:10 PM
To: David Trudgian
On Tue, 17 Nov 2015 14:48:03 +
John Chilton wrote:
> Thanks for the bug report. Somehow Galaxy isn't installing the
> development wheels into the transient Galaxy's virtualenv, I've wiped
> out my planemo caches and I can't reproduce this locally.
From planemo 0.19 to 0.20 I have also found
Sorry David for the long delay. Unfortunately I'm not aware of a
setting to do this, I think each install process handles this on their
own.
This is a problem, perhaps the tool shed code should go through and
ensure directory permissions are set correctly - maybe all user
permissions should be app
On 11/17/2015 01:32 PM, John Chilton wrote:
> Eric - yeah - it should be straight forward to add these to workflow
> editor - it is just sort of a matter of how to represent this I think.
> I don't have any clues.
I do!
Advanced settings -> "Enable tool ordering/dummy IO" -> has a checkbox
When
Eric - yeah - it should be straight forward to add these to workflow
editor - it is just sort of a matter of how to represent this I think.
I don't have any clues.
The relevant commit is at:
https://github.com/galaxyproject/galaxy/commit/e0a5e82bdae407535b9d7c98e3dcf851b63d01a0
This includes exa
Ah, I can see how symlinking could lead to file management issues. Well,
we were trying to avoid the situation where use of our qc tool would
require customizing any subsequent tools in a workflow, and as well,
reduce disk overhead of hundred megabyte files being passed along in a
workflow.
So wo
The first example should now work - maybe your variant of Galaxy was
to old at the time? I added that at the request of Michael Crusoe
during the last virtual contribution fest.
https://github.com/galaxyproject/galaxy/commit/07dd69edd5472afef305fb170f18628a0cf3402d
Otherwise, using ext instead of
On 11/17/2015 01:18 PM, John Chilton wrote:
> The workflow subsystem has the ability to define a connection like
> this (just wait for one tool to pass before calling the next without a
> input/output relationship) but it hasn't been exposed in the workflow
> editor yet.
That's incredibly exciting
Slowly trying to catch up on e-mail after a lot of travel in November
and I answered a variant of this to Damion directly, the most relevant
snippet was:
"
I would not symbolic link the
files though. I would just take the original collection and pipe it
into the next tool and add a dummy input to
On Tue, Nov 17, 2015 at 2:48 PM, John Chilton wrote:
> Thanks for the bug report. Somehow Galaxy isn't installing the
> development wheels into the transient Galaxy's virtualenv, I've wiped
> out my planemo caches and I can't reproduce this locally.
Perhaps unrelated, but I was seeing something s
Thanks for the bug report. Somehow Galaxy isn't installing the
development wheels into the transient Galaxy's virtualenv, I've wiped
out my planemo caches and I can't reproduce this locally.
Can you send me the green log messages at the beginning of the test
command as well as the few lines after
Hi Mic
You said, you had migrated your "Galaxy installation to Postgresql"?
So why did you lose your API key? - I assume by 'loosing' you mean: is
no longer valid, don't you?
Have you forgot to migrate the "api_keys" table? All the keys are stored
there.
Hans-Rudolf
On 11/17/2015 02:10 P
Hello,
I don't know your constraints but you can easily generate a new one:
- User
- API Keys
- Generate a new key now
Gildas
Le 17/11/2015 13:11, Mic a écrit :
Hello,
After I migrated Galaxy installation to Postgresql my API key got
lost. I still know it and would like to add it to the d
Hello,
After I migrated Galaxy installation to Postgresql my API key got lost. I
still know it and would like to add it to the database, but I am not quite
sure how to do it.
How is it possible to add an API key to the database.
Thank you in advance.
Mic
_
Hi Peter,
Thank you for you response.
Mic
On Tue, Nov 17, 2015 at 5:54 PM, Peter Cock
wrote:
> Hi Mic,
>
> There is no single answer. Note I am answering this from
> the perspective of the Galaxy server administrator (who
> likely will get bug reports from their users).
>
> Most of the routes a
Hi Christian,
I think the "cvs" datatype sniffer should be fixed not to accept tab
separated files, to me a clear false positive given Galaxy has a
separate "tabular" format for "tsv" files.
Also surprisingly the "tabular" datatype does not seem to have a sniff
method at all:
https://github.com/
Hi All,
I noticed there is a bug when you read in tab separated files and leave them as
type auto.
These are then identified by
https://github.com/galaxyproject/galaxy/blob/dev/lib/galaxy/datatypes/tabular.py
as "CSV" as the CSV type uses the python module "csv" which can read tab
separated fil
17 matches
Mail list logo
