Join the Galaxy Developers community and develop your own tools
tool_conf.xml
and installs the dependencies.
env.sh
file at the given dependency path that, once sourced, provides the proper binaries.
Tool Shed is a free tool store, with thousands of tools already available
wrapper
or tool definition file
- The XML file that describes to Galaxy how the underlying software works, allowing Galaxy to render UI and execute the software in the right wayrepository
- A versioned code archive with tool(s) in Tool Shed__
config/tool_sheds_conf.xml
:
<tool_sheds>
<tool_shed name="Galaxy main tool shed" url="https://toolshed.g2.bx.psu.edu/" />
</tool_sheds>
G- o to the admin interface and click on “Search Tool Shed”
Select a Tool Shed
Search your tool
Types of repository
$name
)suite_$name
)package_$name_$version
) (gradually removed, replaced by Conda dependencies)
Install the tool
Recommended: use conda
shed_tool_conf.xml
).
If you install the suite all ‘dependency repositories’ will be installed too.
<?xml version="1.0"?>
<repositories description="Pipeline phylogeny">
<repository toolshed="http://testtoolshed.g2.bx.psu.edu"
name="fasta_to_phylip" owner="gandres" changeset_revision="a895633568" />
<repository name="mafft" owner="gandres" />
<repository name="phyml" owner="gandres" />
[…]
</repositories>
Many tools developed by the community on GitHub repositories
Added value:
To achieve the level of reproducibility Galaxy aims for, it needs to be able to:
Linux/MacOS package management is/was:
Conda recipes build packages that are published to channels.
You need to download Galaxy if you plan to:
Even when you plan any of the above sometimes you can leverage pre-configured Docker image or use Cloudlaunch
Optional
config/
*.sample
as declared defaultsintegrated_tool_panel.xml
.The best approach for managing the new integrated_tool_panel.xml
file is to allow Galaxy
to add or remove entries as manually adding or removing them will likely result in undesired behavior.
Manual changes to the file should simply be moving entries around to produce the desired arrangement of your tool panel.
What resolver is going to be used for the tool dependency is determined at runtime
and prioritised in the config file dependency_resolvers_conf.xml
.
<dependency_resolvers>
<tool_shed_packages />
<galaxy_packages />
<galaxy_packages versionless="true" />
<conda />
<conda versionless="true" />
<!-- other resolvers
<homebrew />
-->
</dependency_resolvers>
List of available sheds is defined in tool_sheds_conf.xml
and Galaxy comes with the Main TS enabled and the Test TS disabled.
<?xml version="1.0"?>
<tool_sheds>
<tool_shed name="Galaxy Main Tool Shed" url="https://toolshed.g2.bx.psu.edu/"/>
<!-- Test Tool Shed should be used only for testing purposes.
<tool_shed name="Galaxy Test Tool Shed" url="https://testtoolshed.g2.bx.psu.edu/"/>
-->
</tool_sheds>
The config/galaxy.ini
file contains ~300 options to be configured, grouped by sections:
# File that can be changed by the Galaxy administrator to alter the layout of the
# tool panel. If not present, Galaxy will create it.
integrated_tool_panel_config = integrated_tool_panel.xml
# The dependency resolvers config file specifies an ordering and options for how
# Galaxy resolves tool dependencies (requirement tags in Tool XML).
# The default is
# - Tool Shed for tools installed that way
# - local Galaxy packages
# - then use Conda if available.
dependency_resolvers_config_file = config/dependency_resolvers_conf.xml
# SMTP server configuration
smtp_server = None
smtp_username = None
smtp_password = None
# Datasets in an error state include a link to report the error.
# Those reports will be sent to this address.
error_email_to = None
Require verification that a user’s email is real. You must enable SMTP first.
In galaxy.ini
:
user_activation_on
require users to click link in email before running jobs.activation_grace_period
time (hours) that a user can ‘explore’ Galaxy before activation lockout.inactivity_box_content
message provided to non-activated users.blacklist_file
defines domains in XXX.YYY format that will be rejected as user emails.In galaxy.ini
:
user_library_import_dir
ftp_upload_dir
.allow_library_path_paste
In galaxy.ini
:
require_login
can be enabled to prevent anonymous access.show_welcome_with_login
show welcome page next to login pageallow_user_creation
. When False, admins must create users; often coupled with require_login
.allow_user_dataset_purge
users can purge (permanently delete) their datasets.api_allow_run_as
list of email addresses of API users who can make calls on behalf of other users.expose_dataset_path
users to see the full path of datasets via the “View Details” option in the history.In galaxy.ini
:
admin_users
comma-separated list of admin users’ emailsallow_user_deletion
admins can delete usersallow_user_impersonation
admins can become other users. Great for debugging / user assistance.master_api_key
admin super-key allows many API admin actions without having a real admin user.Admin can: