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 On Fri, Apr 11, 2014 at 12:40 PM, Dooley, Damion <Damion.Dooley@bccdc.ca> wrote:

Sorry about miss-named message. I found a solution which makes me realize this might have been a bit of a python newbie 'duh' issue.

For those who might need something similar, solution is to add a .pth file to site-packages folder of python version that galaxy is running under, e.g. /usr/lib/python2.6/site-packages/galaxy-custom-modules.pth contains 1 line of text: /usr/local/galaxy/shared/python2.6_galaxy_custom_modules

And now if your code imports say: HTMLReportModule = __import__('custom_templates.html_report')

It will look in the python2.6_galaxy_custom_modules folder as well as the tool's folder.

Now is this the best solution? I haven't seen any folder reserved for custom client python method code within a galaxy install, right? I believe this approach lets any number of updates happen to the tool or to galaxy while preserving the customized code module(s).

Thanks for any input,

Damion

P.s If anyone wants an extra helpful detail on this dynamic replacement of a standard tool module with a custom one - this tip lets one work with any module folder depth "a.b.c.d.my_module". If you skip the "fromlist" part then you have to bother with mentioning b.c.d.my_module expressly. E.g. for the HTMLReport class defined in html_report.py,

# See http://stackoverflow.com/questions/769534 HTMLReportModule = __import__('custom_templates.foo.bar.html_report', fromlist=['does not in fact matter what goes here!'])

lets one then simply say:

htmlManager = HTMLReportModule.HTMLReport(...)

...

Message: 2 ... Subject: Re: [galaxy-dev] Can a tool upload a .loc file that is then ... Python code in galaxy tools can import all sorts of modules. Is there a way to add an extra path to the sys.path so that I can include some other python modules that way? I.e. in some galaxy python config file?

I'd like to say in my tool code

HTMLReportModule = __import__(html_template) ... htmlManager = HTMLReportModule.HTMLReport(tagGroup, options, query_stats) htmlManager.render(out_tabular_file, out_html_file)

and in this way provide a switch from a standard report template that my galaxy tool has in its folder, to a custom one that a client has fiddled with and is comfortably outside galaxy's codespace. The html_template variable would have 'templates.html_report' for the stock template, but 'custom_templates.html_report' would pull it from wherever was set in the path. Seems like a secure approach. (I don't want to pass the paths via the browser).

---

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/