Hi David,
in the server I am administering I don't use the Tool Shed dependency resolver and is not much work if you are used to environment modules. For more information, see:


https://docs.galaxyproject.org/en/master/admin/dependency_resolvers.html

Cheers,
Nicola

On 13/04/16 16:42, Martin Čech wrote:
David,

You can have multiple versions of tool 'installed' manually (i.e. without shed).

That said, there is an option of working with the IUC to make the wanted packages to be up-to-date and secure. i am pretty sure any PRs this direction will get merged.

M.

On Wed, Apr 13, 2016 at 11:39 AM David Trudgian <david.trudg...@utsouthwestern.edu <mailto:david.trudg...@utsouthwestern.edu>> wrote:

    Hi Martin,

    Thanks for the input - yes there is going to be maintenance
    headache either way, private tool-shed or not. If we don't go with
    our own tool-shed though, am I right in thinking we lose
    versioning for tools? I.E. installing manually into 'tools' and
    tool_conf.xml I can't use <version> tags like the tool shed stuff
    does in shed_tool.conf. The infosec concern is mainly with
    libraries which are provided by tool-shed dependency package
    installs, not the main software package the tool wrapper is
    calling. With a tool shed it's feasible then we could keep older
    versions of tools/wrappers for reproducibility, rebuilding them
    against updated (but compatible) libraries when there's a security
    issue, perhaps?

    Glad to know that my idea of the workflow isn't totally wrong though.

    Thanks,

    DT

    --
    David Trudgian Ph.D.
    Computational Scientist, BioHPC
    Lyda Hill Department of Bioinformatics
    UT Southwestern Medical Center
    Dallas, TX 75390-9039
    Tel: (214) 648-4833

    From: Martin Čech [mailto:mar...@bx.psu.edu
    <mailto:mar...@bx.psu.edu>]
    Sent: Wednesday, April 13, 2016 8:47 AM
    To: David Trudgian <david.trudg...@utsouthwestern.edu>;
    galaxy-dev@lists.galaxyproject.org
    <mailto:galaxy-dev@lists.galaxyproject.org>
    Subject: Re: [galaxy-dev] Tool shed tools, manual dep installation

    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
    <mailto: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/

___________________________________________________________
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