Hi James,
thanks for your thoughts on abstraction of common tasks.
For most of these things we have now patches in bitbucket.
> Similar recipes could be:
>
> autoconf: default to configure; make; make install, allow providing
> configuration options
https://bitbucket.org/galaxy/galaxy-central/p
Before I went on that tangent, I should have said I of course agree
with 100% of what James said in the original e-mail on this thread.
For what it is worth, I believe the higher-level constructs he
outlined are essential to the long term adoption of the tool shed.
On Tue, Aug 27, 2013 at 1:59 PM,
On Aug 26, 2013, at 11:59 AM, James Taylor wrote:
> On Mon, Aug 26, 2013 at 11:48 AM, John Chilton wrote:
>
>> I think it is interesting that there was push back on providing
>> infrastructure (tool actions) for obtaining CBL from github and
>> performing installs based on it because it was not
On Mon, Aug 26, 2013 at 11:48 AM, John Chilton wrote:
> I think it is interesting that there was push back on providing
> infrastructure (tool actions) for obtaining CBL from github and
> performing installs based on it because it was not in the tool shed
> and therefore less reproducible, but th
James, et. al.
I think it is interesting that there was push back on providing
infrastructure (tool actions) for obtaining CBL from github and
performing installs based on it because it was not in the tool shed
and therefore less reproducible, but the team believes infrastructure
should be put in
All,
I've been seeing some examples of tool_depedencies.xml come across of
the list, and I'm wondering if there are ways that it can be
simplified. When we were first defining these features, we talked
about having high level recipes for certain types of installs. This
could greatly simplify thing