Hi Carlos,

You can certainly add support for a sqlite database datatype to your local 
galaxy instance.  As you say, it may be no more complex / fragile than h5 or 
other binary datatypes - I've not gone far enough down the analysis path to 
provide good reasons why it may or may not be reasonable, so perhaps I spoke 
too soon.  If you have questions about how to add support for new datatypes, 
see our wiki at http://wiki.g2.bx.psu.edu/Admin/Datatypes.

Thanks!

Greg Von Kuster


On Feb 29, 2012, at 11:59 AM, Carlos Borroto wrote:

> Hi Greg,
> 
> Thanks for looking and resolving this issue. After deleting all the
> files in the repo and re-adding them, everything is working as
> expected.
> 
> Please see my comments inline about the other two issues.
> 
> On Tue, Feb 28, 2012 at 1:57 PM, Greg Von Kuster <g...@bx.psu.edu> wrote:
>> Hi Carlos,
>> 
>> I've uploaded a fix for the problem you saw when attempting to reset all 
>> metadata on your cummerbund tool.  Thanks for reporting this issue.
>> 
>> Looking at your change sets, it seems that you are attempting to use the 
>> public tool shed hosted by Penn State as a source code repository for your 
>> tool development efforts.  If so, this is not the intent the public tool 
>> shed - it's intent is rather to share fully functional tools with others in 
>> the Galaxy community ("fully functional" implies that the tools was 
>> developed in an environment that included a Galaxy instance, and the tool 
>> proved to be functional within the Galaxy instance before it was uploaded to 
>> the tool shed).
>> 
>> The tool shed inspects every change set and performs certain functions based 
>> on the content of the change set.  For example, if a change set includes a 
>> tool, an attempt to load the tool will be made to generate information about 
>> the tool.  Data types included in a change set are processed as well.  
>> Because of this, it is best to upload changes to the tool shed that contain 
>> development efforts that are in a "finished" state.
>> 
>> See my additional inline comments and questions in your message.
>> 
>> Thanks!
>> 
>> Greg Von Kuster
>> 
>> On Feb 15, 2012, at 2:24 PM, Carlos Borroto wrote:
>> 
>>> Hi Greg,
>>> 
>>> Thanks for your answer. Would be great to get the tool to preview
>>> correctly but is not a big deal.
>>> 
>>> I'm having a few more problems. I'm getting this error from time to
>>> time when I do "hg push" or even when I delete all files from the
>>> toolshed and upload new ones:
>>> "Version information for the tools included in the cummerbund
>>> repository is missing. Reset all of this repository's metadata in the
>>> tool shed, then set the installed tool versions from the installed
>>> repository's Repository Actions menu."
>> 
>> 
>> The fix that I've pushed to the tool shed should hopefully resolve this 
>> issue.
>> 
>> 
>>> 
>>> Doing a "Reset metadata" in the toolshed doesn't solve this issue. I
>>> can't find how to do "then set the installed tool versions from the
>>> installed repository's Repository Actions menu".
>>> 
>>> I'm also having problem including a datatype with the tool. One of the
>>> outputs of the tool is a sqlite database. I have this
>>> datatypes_conf.xml:
>>> <?xml version="1.0"?>
>>> <datatypes>
>>>  <registration>
>>>    <datatype extension="sqlite" type="galaxy.datatypes.binary:Binary"
>>> mimetype="application/octet-stream" subclass="True"
>>> display_in_upload="true"/>
>>>  </registration>
>>> </datatypes>
>>> 
>>> Still sqlite doesn't appear as an option when I try to upload a file
>>> to Galaxy. The new datatype does appear if I choose the edit a dataset
>>> attributes.
>>> 
>> 
>> I'm  not quite sure what your intentions are here, but attempting to make a 
>> Galaxy datatypes be a sqlite database sounds like it will be complex and 
>> fragile,
>> 
> 
> One of the steps for cummeRbund library is the creation of a sqlite
> database. Generating this database is by far the step taking most of
> the processing time. cummeRbund author made it possible to pass as an
> input a previously generated sqlite database, this greatly cuts the
> processing time for subsequent analysis of the same cuffdiff ouput. I
> don't see why having a sqlite binary data type would be different than
> let say BigBed, BAM or h5 binary data types. Could you please comment
> on why you think it would be complex and fragile?.
> 
>> 
>>> Lastly, when I try to upload a sqlite database I get this error:
>>> "An error occurred running this job: The uploaded binary file contains
>>> inappropriate content"
>> 
>> Uploading a sqlite database to the tool shed will certainly result in this 
>> behavior as our code inspectors will not handle this types o content.
>> 
> 
> Sorry I didn't explained myself clearly, I'm not uploading the sqlite
> database to the tool shed. I'm uploading it to a history so I can use
> it with my newly developed tool.
> 
> Kind regards,
> Carlos
> 
> ___________________________________________________________
> 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:
> 
>  http://lists.bx.psu.edu/
> 


___________________________________________________________
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:

  http://lists.bx.psu.edu/

Reply via email to