We are going in circles here :)
Me:
my hope is for a way of programmatically importing and updating new tools
You:
This is currently possible (and very simple to do) using the Galaxy Admin UI
I would call using the Admin UI not doing some programmatically.
You have done a brilliant job making
John,
Why not separate toolshed updates from dist updates - tool xml and
other code should be robust wrt dist version.
One thing at a time - tools get updated less often than dist I'd
wager, and you can subscribe to repository update emails.
After a dist update you want all the tool functional
Hi John,
I feel this is an important topic and that others in the community are
undoubtedly benefitting from it, so I'm glad you started this discussion.
On Jun 9, 2012, at 12:36 AM, John Chilton wrote:
We don't pull down from bitbucket directly to our production
environment, we pull
Hi John,
On Jun 7, 2012, at 11:55 PM, John Chilton wrote:
I have read through the documentation a couple times, but I still have
a few questions about the recent tool shed enhancements.
At MSI we have a testing environment and a production environment and
I want to make sure the tool
Hello Greg,
Thanks for the prompt and detailed response (though it did make me
sad). I think deploying tested, static components and configurations
to production environments and having production environments not
depending on outside services (like the tool shed) should be
considered best
Hi John,
On Jun 8, 2012, at 1:22 PM, John Chilton wrote:
Hello Greg,
Thanks for the prompt and detailed response (though it did make me
sad). I think deploying tested, static components and configurations
to production environments and having production environments not
depending on
On Fri, Jun 8, 2012 at 3:27 PM, Greg Von Kuster g...@bx.psu.edu wrote:
Hi John,
On Jun 8, 2012, at 1:22 PM, John Chilton wrote:
Hello Greg,
Thanks for the prompt and detailed response (though it did make me
sad). I think deploying tested, static components and configurations
to production
