I think that the best approach for this is an additional ToolDependency status as John proposed a while back as this approach allows for the flexibility needed to support just about anything users may want to do. I haven't had a chance to look at this yet, and I'm currently working on a couple of high priority items. But I can probably take a looke at this probably within the next couple of weeks. If there is an example tool dependency packafge that you have that uses modules, it would really help me with this implementation. Of course, if you want to tak ethis John, it would be much appreciated as well.
Greg Von Kuster On Nov 5, 2013, at 12:03 AM, John Chilton <chil...@msi.umn.edu> wrote: > Simon, > > As you have probably noticed a new stable galaxy was released. It > includes 95% of what we discussed including this implicit check to see > if tool shed packages are enabled. Your help implementing, testing, > and driving these changes was greatly appreciated! > > I couldn't however pull the trigger and mark packages resolved via > modules as "Installed" - so they will still appear to be in an error > state (though your check is in there and they won't attempt to be > installed, they will be just marked as errors). The upshot is you can > change this one line of code in your Galaxy instance to get the > behavior you desire (patch attached). > > The reason I don't want to mark these packages as "Installed" is that > I am worried about Galaxy deployments that maybe want to use modules > are first but transition to tool shed packages down the road. I am > unsure what will happen if things are marked as "Installed" even if no > files corresponding to the installation exist. I think the state > NEVER_INSTALLED may be preferable - but I need to understand more > about what that means. For your own instance, if you are certainly > committed to using modules and not using the tool shed - it should be > easy to apply the above patch. Is this a fair compromise for the time > being? > > Until I can resolve this last issue, the Trello card remains open, but > it should now be quite trivial to modify Galaxy to get the behavior > you desire and hopefully this can serve as a model for how others can > hook in other dependency resolution mechanisms. > > I would be eager to hear how this experiment progresses and how you > feel about the implementation. > > Thanks for your contributions, > -John > > > On Mon, Oct 14, 2013 at 8:33 PM, Guest, Simon > <simon.gu...@agresearch.co.nz> wrote: >> At Mon, 14 Oct 2013 20:22:06 -0500, >> John Chilton wrote: >>> >>> Simon, >>> >>> Very cool! I have two concerns. Rather than adding a new >>> configuration option I think I would prefer to just check the >>> configured dependency resolvers and then infer from them if the tool >>> shed will be used. The configuration option strikes me as having to >>> configure the same thing twice, and this change would make your setup >>> slightly easier. Do you have any objection to me reworking your patch >>> to do this? On the other hand, perhaps it is made more clear to the >>> deployer that they are definitely disabling tool dependency >>> installations if they have to add the explicit option this way. >> >> Hi John, >> >> I have no problem with you reworking it in that way. There are two reasons >> I didn't do that myself: >> >> 1. I would have had to change the interface to the dependency >> resolvers somehow to support this query, and I wasn't sure that was >> a good thing. >> >> 2. I wanted to make it explicit that toolshed package installation was >> disabled in this case, as I thought that would make it more likely >> this change gets accepted into the mainline. >> >> Whichever way you Greg and Dave are happy with is OK by me. >> Actually, I like your implicit approach better, so hope that's the one >> that gets agreed. >> >> cheers, >> Simon > <modules_installed.patch> ___________________________________________________________ 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/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
