-----BEGIN PGP SIGNED MESSAGE-----
On 07/18/2014 09:49 AM, John Chilton wrote:
My understanding of the code is that tool shed dependencies (or
dependencies) will not be available to tool shed datatypes (for
sniffing for instance). Sorry.
I figured as much, not very surprising at all. Dependencies
notwithstanding, the idea has some modicum of merit. There are plenty of
people who have already written great parsers that throw up errors, why
should datatypes re-write them?
If you want to hack up your local instance to resolve dependencies
during the sniffing process that may be possible - my guess is you
could add requirement tags to tools/data_source/upload.xml and the
__SET_METADATA__ tool definition embedded in
lib/galaxy/datatypes/registry.py - though I have not tried this.
Well heck, at that point I'd just use the fact that I know I'm in
lib/galaxy/datatypes to locate the BioPython dependency that was
installed through greps, globs, and finds. Though I'll hold off on that
for a "better" solution.
On Thu, Jul 17, 2014 at 2:24 PM, Peter Cock <p.j.a.cock(a)googlemail.com> wrote:
> On Thu, Jul 17, 2014 at 8:20 PM, Eric Rasche <rasche.eric(a)yandex.ru> wrote:
>> On 07/17/2014 02:11 PM, Peter Cock wrote:
>>> You could do something like that, and we already have
>>> Biopython packages in the ToolShed which can be listed
>>> as dependencies :)
>> If my module depends on the biopython from the toolshed, will that be
>> accessible within a datatype? Would it be as simple as "from Bio import
>> X"? Most of what I've seen of dependencies (and please forgive my lack
>> of knowledge about them) consists of env.sh being sourced with paths to
>> binaries, prior to tool run.
> I don't know - this may well be a gap in the ToolShed
> framework, since thus far most of the datatypes defined
> have been self contained.
> I have asked something similar before (in the context
> of defining automatic file format conversion like the way
> Galaxy can turn FASTA into tabular in input parameters
> expecting tabular), where there could be a binary
>>> However, some things like GenBank are tricky - in order
>>> to tolerate NCBI dumps the Biopython parser will ignore
>>> any free text before the first LOCUS line. A confusing
>>> side effect is most text files are then treated as a
>>> GenBank file with zero records. But if it came back
>>> with some records it is probably OK :)
>> Interesting, very good to know.
>>> Basically Biopython also does not care to offer file
>>> format detection simply because it is a can of worms.
>>> Zen of Python - explicit is better than implicit.
>>> We want you to tell us which format you want to try
>>> parsing it as.
>> Yes! Exactly! Which is why it's perfectly fine here:
>> SeqIO.parse( dataset.file_name, "genbank" )
>> All I want to know is whether or not this parses as a genbank file (and
>> has 1 or more records). BioPython may not do automatic format detection
>> (yuck, agreed), but since I already know I'm looking for a genbank file,
>> simply being able to parse it or not is "good enough".
> With those provisos, you should be OK :)
> 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:
> To search Galaxy mailing lists use the unified search at:
Center for Phage Technology
Texas A&M University
College Station, TX 77843
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
-----END PGP SIGNATURE-----