galaxy-iuc/iuc

Chat with the Intergalactic Utility Commission of Galaxy tool developers

Martin Cech

@martenson

@hepcat72 maybe some conda cache clearing is needed? It should work.

Robert Leach

@hepcat72

Hmmm. It's is still using version 2.006 instead of 2.0013. I think I probably need to bump the wrapper version. I was using some weird version spec and I see that the latest spec says that the <tool version attribute should be tool_version+wrapper_version. I only had wrapper_version.

Robert Leach

@hepcat72

Gee. It still uses 2.006. If I do a which on the tool before doing planemo serve, it's the correct version.

Martin Cech

@martenson

can you share the tool?

Robert Leach

@hepcat72

Sure, although I accidentally got it to run the new version - and I'm not sure why it worked. I accidentally ran planemo serve from the main tool repo directory instead of the specific tool directory and it happened to use the new version when I ran it. Now if I run it from either, it uses the new version. I don't understand it. https://github.com/hepcat72/robs_galaxy_tools/tree/vcfsc13/tools/vcfsamplecompare

Martin Cech

@martenson

sounds like it could be some caching issue

glad it works now

M Bernt

@bernt-matthias

Is it correct that for <param name="in" multiple="true"> there is atm no way to create a list with the same name of elements, i.e. like<collection name="out" type="list" structured_like="in" inherit_format="true">? Would be really handy.

Marius van den Beek

@mvdbeek

yes, that’s right, and I wouldn’t implement this. If you need to derive a structure you should use a collection input

M Bernt

@bernt-matthias

Hmm. Have to think about this.

Marius van den Beek

@mvdbeek

You can take a look around the code, you’ll see that multiple=“true” is very different from a collection input

It might be a nice project to replace that with implicit collection building, I think it could unify some code paths

but that’s just a guess, it might also become more messy

M Bernt

@bernt-matthias

Agree completely. Any other idea on how to set the format of the collection elements? In my case it would be nice to discover data sets, but only get the name from this and take the format from the corresponding input.

Background: OpenMS often requires that the output files have specific extensions which are (of course) not equal to the Galaxy extensions. The only idea I had so far is to rename the files after creation, such that discovering works.

Marius van den Beek

@mvdbeek

is this a 1 to 1 relationship ? each input produces one output but you need all the inputs for tool execution ?

M Bernt

@bernt-matthias

Yep, exactly.

From tool programming perspective it seems best (at least in the amount of needed code) to have an input and an output collection. But I'm wondering about the usability if I force the users into forming a collection. Using a multiple="true" input is just more flexible.

Marius van den Beek

@mvdbeek

isn’t this going to be quite messy if you have more than 2 inputs ?

ok, exaggrating here, but I easily get lost when a tool produces more than 5 outputs

this would be less of an issue if you produce a collection output

M Bernt

@bernt-matthias

I just create a folder for each input and output for storing files and links.

Marius van den Beek

@mvdbeek

you mean in the tool ?

I was talking about the history

M Bernt

@bernt-matthias

Yes - in the tool command sections

Marius van den Beek

@mvdbeek

the tool should be as complex as necessary

the history should be as simple as possible IMO

though heterogenous collections are a pain as well

as you would create there

hmm, not sure we have a great solution there

I guess discovering the output and sniffing could work ?

but if you know the formats it’s probably best to rename as the sniffers aren’t perfect

M Bernt

@bernt-matthias

Most of the time there is one output (and potentially some optional ones) .. so the user can decide how much mess is wanted/needed .. the outputs are differentiated by name.

Marius van den Beek

@mvdbeek

but if you just have one output why would you want to use inherit_format ?

do you have the tool somewhere ?

M Bernt

@bernt-matthias

Sniffing might be an option .. and appealingly simple .. but there are some very under specified data types used in OpenMS for which sniffing does not work.

I could post the a ctd file that I try to autotranslate.

In the end I just want to set the format of the output and I know that it is the same as the input, but there are multiple possible input formats.

Marius van den Beek

@mvdbeek

how do you derive the format from multiple inputs ?

I am still lost here. This should work fine with collection input if you set inherit_format. If you use multiple=“true” you need to create an arbitrary number of outputs using discover_datasets. This will be difficult to impossible to use in workflows

M Bernt

@bernt-matthias

Good points. What is the limiting point for the usability in workflows, i.e. in which case(s) multiple=“true” inputs do not work in work flows?

Marius van den Beek

@mvdbeek

oh, that works fine, discovered outputs aren’t usable

there’s no output to attach them to

there is a single, primary dataset, but I guess that won’t be of much/any use

M Bernt

@bernt-matthias

So if you have data with discover_outputs (which I would understand) or also if you have a collection with discover_outputs? I will always have the later case.

... but I have to admit that I have a few cases where I abuses data+discover to set the format, but its always just a single data set .. so in this case the single data set is of use :) Nice

Marius van den Beek

@mvdbeek

yeah, if the discovered outputs are inside a collection it’s fine, you’ll have the collection output to work with

John Chilton

@jmchilton

I’m not following the conversation completely - but if the problem is just extensions not matching you can probably fix it with setting up a galaxy.json file

M Bernt

@bernt-matthias

Oha .. something new to learn .. is there something to read?

Sounds better than looking at the line of code that might do the workaround:

preprocessing += "${ ' && '.join([ \"ln -s '%s' '"+actual_parameter+"/%s.%s'\" % (_, re.sub('[^\w\-_]', '_', _.element_identifier), _.ext) for _ in $" + actual_parameter + " if _ ]) } && \n"

looks like perl in terms of readability .. lol

Yvan Le Bras

@yvanlebras

;)

M Bernt

@bernt-matthias

Lets assume I have a select parameter with multiple="true". For a test can I somehow express a value that contains a comma?

for options without comma (e.g. "Option A" and "Option B") it would be value="Option A,Option B"
but what if the option value contains a comma (e.g. "Option,A" and "Option,B")

Can one have something like

<param>
  <value="Option,A"/> 
  <value="Option,B"/>
</param>

Where communities thrive

People

Repo info

Activity