I am concerned about having to merge those changes later on so thank you for confirming
I was wondering if maybe these things were a moot point now. Certainly bam and sniff are
built in? Here is additional code found in their older hack:
data_type = 'multi-byte char'
ext = sniff.guess_ext( dataset.path, is_multi_byte=True )
# Is dataset content supported sniffable binary?
elif check_bam( dataset.path ):
ext = 'bam'
data_type = 'bam'
elif check_sff( dataset.path ):
ext = 'sff'
data_type = 'sff'
elif check_celstgz( dataset.path ):
ext = 'cels.tgz'
data_type = 'cels.tgz'
We have added info to the datatypes_conf.xml file for other data types they need to
support in their tools so maybe I can just add this cels.tgz info there too. I will have
to find someone who knows python better than I do to tell me what's going on in their
additions to the upload.py file.
From: Peter Cock [mailto:firstname.lastname@example.org]
Sent: Thursday, August 07, 2014 11:35 AM
To: Sajdak, Doris
Cc: Galaxy Dev
Subject: Re: [galaxy-dev] changes to upload.py
On Thu, Aug 7, 2014 at 4:29 PM, Sajdak, Doris <djm29(a)buffalo.edu> wrote:
I’m in an odd situation: I was given an older version of Galaxy with
additional tools built into it by a new faculty member. He brought
this from his former institutions and wanted us to run his Galaxy
instance on our systems. We don’t want to support several instances
so we agreed to put his tools into our Galaxy implementation.
However, we are running into all kinds of snags. The latest issue is
that we realized changes have been made to upload.py to allow for
additional data types. Here’s an example of what I mean:
def check_bam( temp_name ):
return Bam().sniff( temp_name )
def check_sff( temp_name ):
return Sff().sniff( temp_name )
def check_celstgz( temp_name ):
return CelsTgz().sniff( temp_name )
While this doesn’t seem like a big deal to add those changes into our
installation, I’m concerned that doing so will make us unable to
update Galaxy in the future. Can you either confirm or deny that
changes to upload.py on our system will be overwritten with Galaxy updates?
That will cause you trouble with having to merge any future changes to upload.py as well.
In this case, the sniffing should be handled via the Galaxy datatypes mechanism (see
datatypes_conf.xml for instance), so these hacks may not be needed anymore?