Hello,
I have a created an answer for this question in the planemo tool development tutorial:
http://planemo.readthedocs.org/en/latest/writing_standalone.html#determined-...
From the docs:
The variable ``$__user_email__`` (as well as ``$__user_name__`` and ``$__user_id__``) is available when building up your command in the tool's ``<command>`` block. The following tool demonstrates the use of this and a few other special parameters available to all tools.
- `special_params.xml https://github.com/galaxyproject/galaxy/blob/dev/test/functional/tools/special_params.xml`__
Hope this helps, -John
On Wed, Apr 15, 2015 at 8:51 AM, Wang, Yu Yu.Wang@lrz.de wrote:
Hi,
Is there a way to query the actual name of the user, who is logged into galaxy and submitted the workflow ($REMOTE_USER), from inside a galaxy tool
when galaxy is configured for external authentication using an apache server?
It seems like galaxy passes this variable to scripts like 'drmaa_external_runner.py' but I could not find it in the environment of a tool
which has been started via e.g. python ( using <command interpreter="python"> in the xml-file of the tool)."
Cheers, Yu
di29her wang@lrz.de
On 13 Apr 2015, at 18:00, galaxy-dev-request@lists.galaxyproject.org wrote:
Send galaxy-dev mailing list submissions to galaxy-dev@lists.galaxyproject.org
To subscribe or unsubscribe via the World Wide Web, visit https://lists.galaxyproject.org/listinfo/galaxy-dev or, via email, send a message with subject or body 'help' to galaxy-dev-request@lists.galaxyproject.org
You can reach the person managing the list at galaxy-dev-owner@lists.galaxyproject.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of galaxy-dev digest..."
HEY! This is important! If you reply to a thread in a digest, please
- Change the subject of your response from "Galaxy-dev Digest Vol ..." to
the original subject for the thread. 2. Strip out everything else in the digest that is not part of the thread you are responding to.
Why?
- This will keep the subject meaningful. People will have some idea from
the subject line if they should read it or not. 2. Not doing this greatly increases the number of emails that match search queries, but that aren't actually informative.
Today's Topics:
- Re: Strange repository dependency behavior with toolshed-installed naive_variant_caller (Martin Čech)
Message: 1 Date: Mon, 13 Apr 2015 14:27:10 +0000 From: Martin Čech marten@bx.psu.edu To: Brian Claywell bclaywel@fredhutch.org Cc: galaxy-dev@lists.galaxyproject.org Subject: Re: [galaxy-dev] Strange repository dependency behavior with toolshed-installed naive_variant_caller Message-ID: CAHKBquFw66cXyss7KjExM4-mpdK0P_TLT_xtCOBEK4pLs3OYOg@mail.gmail.com Content-Type: text/plain; charset="utf-8"
Hello Brian,
we have made some changes in the past month that might address the issue you are having. Are you still encountering problems? If so could you please try re-installing the tools again?
thank you
Martin
On Tue, Feb 24, 2015 at 5:15 PM Brian Claywell bclaywel@fredhutch.org wrote:
Hi Martin,
Thanks for the prompt reply! My responses are inline below.
On Tue, Feb 24, 2015 at 8:26 AM, Martin Čech marten@bx.psu.edu wrote:
Are you using Admin UI for installation or API scripts?
The admin UI exclusively.
Does the 'installed tool shed repos' page show multiple installations of the same package (with the same changesets)? If so what are the states of these?
Yes -- the iuc package_numpy_1_7 revision a4bdc17eed4a is listed twice, with both showing the green "Installed" status. Interestingly the installed repo page shows that they're installed in different locations:
(...)/shed_tools/ toolshed.g2.bx.psu.edu/repos/iuc/package_numpy_1_7/ef12a3a11d5b/package_numpy_1_7 (...)/shed_tools/ toolshed.g2.bx.psu.edu/repos/iuc/package_numpy_1_7/a4bdc17eed4a/package_numpy_1_7
At one point during the troubleshooting steps I described in my original email, package_pybamparser_0_0_1 and package_pybamtools_0_0_1 showed up in the same way, with two records each having the same revision and a green "Installed" status.
If you check on the filesystem in the
{{configured_dependency_dir}}/path/to/duplicated/package do you see any strange stuff/duplication?
I didn't see anything that struck me as out of the ordinary. Here's a gist of the directory structures for the affected packages under both shed_tools and tool_deps:
https://gist.github.com/bcclaywell/23c0b274f2d4bd0d659f
How big is your Galaxy in terms of installed tools, complexity of setup
and traffic?
I don't think it's terribly big -- we have a couple of large tool suites like BEDTools, the gops interval operations suites, GATK 1 and 2, etc, and then maybe 15-20 other tools and their dependencies?
Our setup isn't very complex, either; Galaxy is running with one web process and one handler process behind an nginx reverse proxy, all running on a single machine. Jobs are submitted to our slurm cluster via the SSH CLI runner.
Traffic is pretty low -- we're just now rolling out of beta.
Cheers,
Brian
-- Brian Claywell | programmer/analyst Matsen Group | http://matsen.fredhutch.org http://matsen.fhcrc.org/ Fred Hutchinson Cancer Research Center