Hi David,

one thing that you might be missing is that the wrapper for the
infosec-approved version might not exist yet (you would have to adapt the
older shed-wrapped version if there were any relevant changes). But this
largely depends on what software you want to use.

Besides that your flow seems quite accurate. I would probably argue against
own tool shed, as the maintenance overhead will probably not be worth it
for you.

Let us know if we can help in any way,

thank you for using Galaxy.

Martin

On Tue, Apr 12, 2016 at 5:42 PM David Trudgian <
david.trudg...@utsouthwestern.edu> wrote:

> Hi All,
>
>
>
> I’m currently caught between the requests of our Galaxy users to install
> things from main tool-shed, and our information security dept’s concerns
> r.e. the automated installation of tool-deps on our systems. Due to
> restrictive web access policies for servers here our galaxy server can’t
> access SourceForge, where many tool-dep downloads are. A request to unblock
> this for a particular tool-dep package led to our infosec justifiably
> raising concerns r.e. a tool-dep package that is quite out of date (details
> sent off list previously). We’re now currently unable to install tool-shed
> tools that users have requested.
>
>
>
> The current proposal from our infosec dept is to get all our deps from
> system repos etc. However the way I’m aware of implementing this for
> tool-shed tools, which need to run across our cluster, would be something
> pretty arduous like:
>
>
>
> * Clone the tool from the upstream toolshed repo
>
> * Edit the tool code to remove the package requirements
>
> * Identify and install all the requirements on the cluster as system pkgs
> / environment modules – with attention to versions so things work as
> expected
>
> * Edit the tool code so it knows to load the right environment modules /
> set right PATH when it runs
>
> * Install the tool into our galaxy ‘tools’ dir , not the ‘shed_tools’
>
> * Manually add the tool to galaxy’s tool_conf.xml.main
>
> * Schedule downtime to restart galaxy
>
> * Test things out
>
>
>
> …. or we have to host our own tool shed, import tools we want from
> upstream, edit out the package requirements, provide the deps ourselves.
> These have all the headaches of merging things in when upstream shed-tools
> change.
>
>
>
> Just wondering if I’m missing anything? I know you can turn off ‘handle
> repository dependencies’ when installing a tool, but the tool still defines
> ‘requirements’ in its XML file and shows ‘Missing repository/tool
> dependencies’ in the Admin.  Has anyone had any experience of dealing with
> this kind of situation?
>
>
>
> Many thanks!
>
>
>
> --
> David Trudgian Ph.D.
> Computational Scientist, BioHPC
>
> Lyda Hill Department of Bioinformatics
> UT Southwestern Medical Center
> Dallas, TX 75390-9039
> Tel: (214) 648-4833
>
>
>
> ------------------------------
>
> UT Southwestern
>
> Medical Center
>
> The future of medicine, today.
> ___________________________________________________________
> 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:
>   https://lists.galaxyproject.org/
>
> To search Galaxy mailing lists use the unified search at:
>   http://galaxyproject.org/search/mailinglists/
___________________________________________________________
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:
  https://lists.galaxyproject.org/

To search Galaxy mailing lists use the unified search at:
  http://galaxyproject.org/search/mailinglists/

Reply via email to