Re: [galaxy-dev] Fwd: Dynamically Generated Tools
Ah. Forgive me for not paying attention to that requirement. Tools usually run as the Galaxy user so only local admins can do that at present because allowing a non-admin user to install a newly generated tool, especially on a public site opens up some interesting security challenges. I think it would be hard to sell as a new feature unless you've figured out how to prevent potential mischief from miscreant users? On Thu, Jul 18, 2013 at 11:33 PM, Michael E. Cotterell mepcotter...@gmail.com wrote: This doesn't seem to fit into the use case that my colleagues have described to me. Our tool, used within Galaxy, creates/builds/generates new tools for Web service operations. Once a user uses our tool to generate a Web service tool, it should be visible and usable to them. Currently, in order to accomplish this, we have to manually modify the tool_config.xml file, however, I don't think we should release a tool that does that. Sincerely, Michael E. Cotterell Ph.D. Student in Computer Science, University of Georgia Instructor of Record, Graduate RA TA, University of Georgia Faculty Liaison, CS Graduate Student Association, University of Georgia mepcotter...@gmail.com (mailto:mepcotter...@gmail.com) mepc...@uga.edu (mailto:mepc...@uga.edu) m...@cs.uga.edu (mailto:m...@cs.uga.edu) http://michaelcotterell.com/ On Wednesday, July 17, 2013 at 10:26 PM, Ross wrote: AFAIK it's not yet possible, but a tool shed API to expose subversion hooks for repository creation and update is a logical development which is already on the radar AFAIK. For the bigger picture of complexity for the user, I think some key clarifications required include: which 'user' is experiencing complexity; how big a barrier it is to generating tools; how readily can we make it go away; how much will it help? Tool builders (even 'users' of the TF) might reasonably be expected to have a capacity for substantial complexity that the end user of the generated tools should not need to possess - after all, once a generated tool is installed in Galaxy, the Galaxy user can't tell the difference and sees no more complexity from the generated tool than a hand written one. On absent local tool sheds: it's trivial to run a toolshed on a dev laptop and not hard to run in production - but tool makers can always use the public test and main TS if they want to distribute new tools so I'm not sure how big a barrier a missing local toolshed really is. On Thu, Jul 18, 2013 at 12:08 PM, Michael E. Cotterell mepcotter...@gmail.com (mailto:mepcotter...@gmail.com) wrote: I didn't mean to imply it was unclear. It definitely made sense. I completely agree with you. However, is there for a way (maybe via the toolshed api) for my tool to push these tools to a TS repo? Also, doesn't that add some more complexity for the user? Not everyone runs a local tool shed. Sincerely, Michael E. Cotterell Ph.D. Student in Computer Science, University of Georgia Instructor of Record, Graduate RA TA, University of Georgia Faculty Liaison, CS Graduate Student Association, University of Georgia mepcotter...@gmail.com (mailto:mepcotter...@gmail.com) (mailto: mepcotter...@gmail.com) mepc...@uga.edu (mailto:mepc...@uga.edu) (mailto:mepc...@uga.edu) m...@cs.uga.edu (mailto:m...@cs.uga.edu) (mailto:m...@cs.uga.edu) http://michaelcotterell.com/ On Wednesday, July 17, 2013 at 10:05 PM, Ross wrote: Sorry if my post was rambling and unclear. Here's the executive summary for what it's worth: IMHO, a Galaxy tool that generates tools should emit them as tool shed compatible artefacts, ready for uploading to a TS repository for automated installation to any target instance. On Thu, Jul 18, 2013 at 11:25 AM, Michael E. Cotterell mepcotter...@gmail.com (mailto:mepcotter...@gmail.com) (mailto: mepcotter...@gmail.com) wrote: Ross, Thanks for the comments. I've already made my main tool tool_shed compatible. What I'm wondering about is what do I do with the tools that my tool creates? Sincerely, Michael E. Cotterell Ph.D. Student in Computer Science, University of Georgia Instructor of Record, Graduate RA TA, University of Georgia Faculty Liaison, CS Graduate Student Association, University of Georgia mepcotter...@gmail.com (mailto:mepcotter...@gmail.com) (mailto: mepcotter...@gmail.com) (mailto:mepcotter...@gmail.com) mepc...@uga.edu (mailto:mepc...@uga.edu) (mailto:mepc...@uga.edu) (mailto:mepc...@uga.edu) m...@cs.uga.edu (mailto:m...@cs.uga.edu) (mailto:m...@cs.uga.edu) (mailto:m...@cs.uga.edu) http://michaelcotterell.com/ On Wednesday, July 17, 2013 at 7:44 PM, Ross wrote: Hi, Michael, As others have said, in the long term, tool wrappers and their dependencies will be distributed and installed through tool sheds
[galaxy-dev] Fwd: Dynamically Generated Tools
AFAIK it's not yet possible, but a tool shed API to expose subversion hooks for repository creation and update is a logical development which is already on the radar AFAIK. For the bigger picture of complexity for the user, I think some key clarifications required include: which 'user' is experiencing complexity; how big a barrier it is to generating tools; how readily can we make it go away; how much will it help? Tool builders (even 'users' of the TF) might reasonably be expected to have a capacity for substantial complexity that the end user of the generated tools should not need to possess - after all, once a generated tool is installed in Galaxy, the Galaxy user can't tell the difference and sees no more complexity from the generated tool than a hand written one. On absent local tool sheds: it's trivial to run a toolshed on a dev laptop and not hard to run in production - but tool makers can always use the public test and main TS if they want to distribute new tools so I'm not sure how big a barrier a missing local toolshed really is. On Thu, Jul 18, 2013 at 12:08 PM, Michael E. Cotterell mepcotter...@gmail.com wrote: I didn't mean to imply it was unclear. It definitely made sense. I completely agree with you. However, is there for a way (maybe via the toolshed api) for my tool to push these tools to a TS repo? Also, doesn't that add some more complexity for the user? Not everyone runs a local tool shed. Sincerely, Michael E. Cotterell Ph.D. Student in Computer Science, University of Georgia Instructor of Record, Graduate RA TA, University of Georgia Faculty Liaison, CS Graduate Student Association, University of Georgia mepcotter...@gmail.com (mailto:mepcotter...@gmail.com) mepc...@uga.edu (mailto:mepc...@uga.edu) m...@cs.uga.edu (mailto:m...@cs.uga.edu) http://michaelcotterell.com/ On Wednesday, July 17, 2013 at 10:05 PM, Ross wrote: Sorry if my post was rambling and unclear. Here's the executive summary for what it's worth: IMHO, a Galaxy tool that generates tools should emit them as tool shed compatible artefacts, ready for uploading to a TS repository for automated installation to any target instance. On Thu, Jul 18, 2013 at 11:25 AM, Michael E. Cotterell mepcotter...@gmail.com (mailto:mepcotter...@gmail.com) wrote: Ross, Thanks for the comments. I've already made my main tool tool_shed compatible. What I'm wondering about is what do I do with the tools that my tool creates? Sincerely, Michael E. Cotterell Ph.D. Student in Computer Science, University of Georgia Instructor of Record, Graduate RA TA, University of Georgia Faculty Liaison, CS Graduate Student Association, University of Georgia mepcotter...@gmail.com (mailto:mepcotter...@gmail.com) (mailto: mepcotter...@gmail.com) mepc...@uga.edu (mailto:mepc...@uga.edu) (mailto:mepc...@uga.edu) m...@cs.uga.edu (mailto:m...@cs.uga.edu) (mailto:m...@cs.uga.edu) http://michaelcotterell.com/ On Wednesday, July 17, 2013 at 7:44 PM, Ross wrote: Hi, Michael, As others have said, in the long term, tool wrappers and their dependencies will be distributed and installed through tool sheds rather than being distributed with Galaxy source, so you might want to plan to generate and upload tool shed compatible archives from the get-go. The test and main tool sheds contain plenty of examples and Björn's tools exercise pretty much all of the functionality - you can browse the repo structure which is identical to the gz archive structure you need to upload to a new repo, or download the repo as a gz, unpack it and get exactly the kind of directory structure and contents you need to emulate for your tools. Once you have a working tool packaging the archive up is straightforward. The format for tool shed repo uploads and syntax for the tags used to define dependencies is very well documented in the tool shed section of the wiki. As Björn points out, the tool factory python wrapper might be a useful source of ideas and perhaps code. Your tool generator will need to do something similar to write the content and generate complete tool shed archives. When generating a new tool, the TF uses an ugly XML wrapper generator (contributed improvements would be very welcome!) and (probably more usefully) the few lines of code you need to package up the functional test data and the XML and wrapper if you need one in toolshed archive format. On Thu, Jul 18, 2013 at 5:30 AM, Björn Grüning bjoern.gruen...@pharmazie.uni-freiburg.de (mailto: bjoern.gruen...@pharmazie.uni-freiburg.de) (mailto: bjoern.gruen...@pharmazie.uni-freiburg.de) wrote: Hi Michael, I think you will enter new ground with your tool. The closest tool that will do something similar is Ross toolfactory, I think: http://toolshed.g2.bx.psu.edu/view/fubar/toolfactory For me one question is, do you really want to
