Is your datatype lading into your Galaxy instance correctly (either when you start your Galaxy instance or when you install your tool from the tool shed)? If so, it should be displaying in the upload form. What does your paster log say? On Feb 29, 2012, at 1:06 PM, Carlos Borroto wrote:
Hi Greg,
I did follow that link and I think the datatypes_conf.xml in the tool repository is correctly written: <?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>
I thought by adding display_in_upload="true" that would make the datatype to appear as an option when uploading a file, but this is not happening. Do I need to declare type as for example "galaxy.datatypes.binary:Sqlite3" for this to work? If I have to, I'm guessing I would have to do what is explained here: http://wiki.g2.bx.psu.edu/Tool%20Shed#Including_proprietary_data_types_that_...
Thanks, Carlos
On Wed, Feb 29, 2012 at 12:14 PM, Greg Von Kuster <greg@bx.psu.edu> wrote:
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 <greg@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:
___________________________________________________________ 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: