On Wed, Apr 16, 2014 at 12:16 PM, Dooley, Damion <damion.doo...@bccdc.ca> wrote:
> Thanks for your input, John.  I see, so from what you say, anything installed 
> via pip in the virtual environment then exists in the module/class include 
> namespace within galaxy python command line tool code.  Good to know.
>
> I'll note that this approach is compatible with toolshed tools (I'm testing 
> it via one) because it relies on a galaxy admin managed .loc file to list the 
> generic and customized reporting modules.  The (toolshed) reporting tool 
> ships with a .loc file that doesn't reference any customized reports, e.g. 
> blast_reporting_templates.loc.sample is
>
>    #value       name    description
>    # Add list of html templates here
>    templates.html_report        Standard Report Provides report with sections 
> and table sections
>
> And then a galaxy admin adds an entry:
>   # Customized templates listed below
>   templates_custom.html_report  Customized report       Test customized report
>
> Task for getting a customized report in place does require manual steps 
> though: customized module, addition of the .pth file, and editing of the 
> above .loc file.

Cool to know, that is very nice. However, I meant that these steps
requiring external modules outside the context of job execution will
require the Galaxy admin to setup these dependencies - they are not
installed with the tool shed installs. It sounds like this is not a
large problem though. Glad this working for you.

-John

>
> Damion
> ------------------------------
>
> Message: 4
> Date: Wed, 16 Apr 2014 06:47:14 -0500
> From: John Chilton <jmchil...@gmail.com>
> To: "Dooley, Damion" <damion.doo...@bccdc.ca>
> Cc: "galaxy-dev@lists.bx.psu.edu" <galaxy-dev@lists.bx.psu.edu>
> Subject: Re: [galaxy-dev] Can a tool upload a .loc file that is then
>         ... RENAME: custom galaxy tool python modules
> Message-ID:
>         <CANwbokfAJCLWH7afNk-s7yZXKcz6pWYVq4Ttn0Q=uezvfxt...@mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> If this is working it sounds reasonable. I think my approach might be
> to setup Galaxy inside a virtualenv (as recommended here
> https://wiki.galaxyproject.org/Admin/Config/Performance/ProductionServer)
> and just install your extra dependencies inside that virtualenv using
> pip.
>
> $ . <path_to_virtualenv>/bin/activate
> $ pip install dependency1
> $ pip install dependency2
> ...
>
> After that you should be able to just do a normal Python import.
>
> I think you have another open question about the next steps of this -
> but just to make it explicit - everything is going to work better in
> "the Galaxy ecosystem" if you can avoid calling code from tools like
> this and just use the sort of stock options. For instance - neither of
> these approaches will work with the tool shed. Sometimes that is not
> possible - I understand that - but I just thought I would put the
> disclaimer out there.
>
> -John
> ___________________________________________________________
> 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/

___________________________________________________________
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/

Reply via email to