Welcome to galaxy-lib’s documentation!¶
Contents:
Overview¶
A small subset of the Galaxy project for reuse outside the core. This subset has minimal dependencies and should be Python 3 compatible.
- Free software: Academic Free License version 3.0
- Documentation: https://galaxy-lib.readthedocs.org.
- Code: https://github.com/galaxyproject/galaxy-lib
Installation¶
pip¶
For a traditional Python installation of galaxy-lib, first set up a virtualenv
for galaxy-lib
(this example creates a new one in .venv
) and then
install with pip
.
$ virtualenv .venv; . .venv/bin/activate
$ pip install galaxy-lib
When installed this way, galaxy-lib can be upgraded as follows:
$ . .venv/bin/activate
$ pip install -U galaxy-lib
To install or update to the latest development branch of galaxy-lib with pip
,
use the following pip install
idiom instead:
$ pip install -U git+git://github.com/galaxyproject/galaxy-lib.git
Conda¶
Another approach for installing galaxy-lib is to use Conda (most easily obtained via the Miniconda Python distribution). Afterwards run the following commands.
$ conda config --add channels bioconda
$ conda install galaxy-lib
Galaxy Project Code of Conduct¶
This code of conduct outlines our expectations for participants within the Galaxy community, as well as steps to reporting unacceptable behavior. We are committed to providing a welcoming and inspiring community for all and expect our code of conduct to be honored. Anyone who violates this code of conduct may be banned from the community.
Our open source community strives to:
- Be friendly and patient.
- Be welcoming: We strive to be a community that welcomes and supports people of all backgrounds and identities. This includes, but is not limited to members of any race, ethnicity, culture, national origin, colour, immigration status, social and economic class, educational level, sex, sexual orientation, gender identity and expression, age, size, family status, political belief, religion, and mental and physical ability.
- Be considerate: Your work will be used by other people, and you in turn will depend on the work of others. Any decision you take will affect users and colleagues, and you should take those consequences into account when making decisions. Remember that we’re a world-wide community, so you might not be communicating in someone else’s primary language.
- Be respectful: Not all of us will agree all the time, but disagreement is no excuse for poor behavior and poor manners. We might all experience some frustration now and then, but we cannot allow that frustration to turn into a personal attack. It’s important to remember that a community where people feel uncomfortable or threatened is not a productive one.
- Be careful in the words that we choose: We are a community of professionals, and we conduct ourselves professionally. Be kind to others. Do not insult or put down other participants. Harassment and other exclusionary behavior aren’t acceptable. This includes, but is not limited to: Violent threats or language directed against another person, Discriminatory jokes and language, Posting sexually explicit or violent material, Posting (or threatening to post) other people’s personally identifying information (“doxing”), Personal insults, especially those using racist or sexist terms, Unwelcome sexual attention, Advocating for, or encouraging, any of the above behavior, Repeated harassment of others. In general, if someone asks you to stop, then stop.
- Try to understand why we disagree: Disagreements, both social and technical, happen all the time. It is important that we resolve disagreements and differing views constructively. Remember that we’re different. Diversity contributes to the strength of our community, which is composed of people from a wide range of backgrounds. Different people have different perspectives on issues. Being unable to understand why someone holds a viewpoint doesn’t mean that they’re wrong. Don’t forget that it is human to err and blaming each other doesn’t get us anywhere. Instead, focus on helping to resolve issues and learning from mistakes.
### Diversity Statement
We encourage everyone to participate and are committed to building a community for all. Although we will fail at times, we seek to treat everyone both as fairly and equally as possible. Whenever a participant has made a mistake, we expect them to take responsibility for it. If someone has been harmed or offended, it is our responsibility to listen carefully and respectfully, and do our best to right the wrong.
Although this list cannot be exhaustive, we explicitly honor diversity in age, gender, gender identity or expression, culture, ethnicity, language, national origin, political beliefs, profession, race, religion, sexual orientation, socioeconomic status, and technical ability. We will not tolerate discrimination based on any of the protected characteristics above, including participants with disabilities.
### Reporting Issues
If you experience or witness unacceptable behavior, or have any other concerns, please report it by contacting Dave Clements (clementsgalaxy@gmail.com). To report an issue involving Dave Clements please email James Taylor (james@taylorlab.org). All reports will be handled with discretion. In your report please include:
- Your contact information.
- Names (real, nicknames, or pseudonyms) of any individuals involved. If there are additional witnesses, please include them as well. Your account of what occurred, and if you believe the incident is ongoing. If there is a publicly available record (e.g. a mailing list archive or a public IRC logger), please include a link.
- Any additional information that may be helpful.
After filing a report, a representative will contact you personally, review the incident, follow up with any additional questions, and make a decision as to how to respond. If the person who is harassing you is part of the response team, they will recuse themselves from handling your incident. If the complaint originates from a member of the response team, it will be handled by a different member of the response team. We will respect confidentiality requests for the purpose of protecting victims of abuse.
### Attribution & Acknowledgements
This code of conduct is based on the Open Code of Conduct from the TODOGroup.
Contributing¶
It is likely best you contribute to the Galaxy project directly.
galaxy-lib Topics¶
The Mulled Toolkit¶
The mulled toolkit distributed as part of galaxy-lib allows for the automatic generation and testing of containers from Conda packages. These containers can be used stand alone on the command-line or automatically as part of properly annotated Galaxy or CWL tools.
This documentation describes the low-level mulled toolkit, but for information on using these containers automatically with tools check out these other documents:
The mulled toolkit utilizes mulled with involucro in an automatic way to build and test containers. This for example has been used to convert all packages in bioconda into Linux Containers (Docker and rkt at the moment) and made available via the BioContainers Quay.io account.
Once you have installed galaxy-lib,
several mulled utilities should be configured on your PATH
including
mulled-search
, mulled-build
, mulled-build-channel
, and
mulled-build-tool
.
Some examples of using these tools are described below.
Search for containers¶
This will search for containers in the biocontainers organisation.
$ mulled-search -s vsearch -o biocontainers
Build all packages from bioconda from the last 24h¶
The BioConda community is building a container for every package they create with a command similar to this.
$ mulled-build-channel --channel bioconda --namespace biocontainers \
--involucro-path ./involucro --recipes-dir ./bioconda-recipes --diff-hours 25 build
Building Docker containers for local Conda packages¶
Conda packages can be tested with creating a busybox based container for this particular package in the following way. This also demonstrates how you can build a container locally and on-the-fly.
> we modified the samtools package to version 3.0 to make clear we are using a local version
- build your recipe
$ conda build recipes/samtools
- index your local builds
$ conda index /home/bag/miniconda3/conda-bld/linux-64/
- build a container for your local package
$ mulled-build build-and-test 'samtools=3.0--0' \
-c iuc,conda-forge,bioconda,file://home/bag/miniconda3/conda-bld/ --test 'samtools --help'
The --0
indicates the build version of the conda package. It is recommended to specify this number otherwise
you will override already existing images. For Python Conda packages this extension might look like this --py35_1
.
Build, test and push a conda-forge package to biocontainers¶
> You need to have write access to the biocontainers repository
You can build packages from other Conda channels as well, not only from BioConda. pandoc
is available from the
conda-forge channel and conda-forge is also enabled by default in Galaxy. To build pandoc
and push it to biocontainrs
you could do something along these lines.
$ mulled-build build-and-test 'pandoc=1.17.2--0' --test 'pandoc --help' -n biocontainers
$ mulled-build push 'pandoc=1.17.2--0' --test 'pandoc --help' -n biocontainers
Build, test and push containers to your own quay.io repository¶
> You need to have admin access to the quay.io organization or user. > If using travis and wish to encrypt your keys you will need to have the travis gem installed.
- Generate the QUAY_OAUTH_TOKEN and add it to your .travis.yml
If you want your repositories to be public you must give involucro your QUAY_OAUTH_TOKEN token. If you want private containers skip this step.
First head on over to your quay.io dashboard and create a new application for the organization or user. This token will need to have permissions to create new repositories. You can get the full instructions here <https://docs.quay.io/api/> under the ‘Applications and Tokens’ heading. Once your key appears be sure to store it someplace secure! I will say you are storing it in a plain text file called ~/tokens/quay-oauth-token.
$ cd my-recipes-repo
##Using Travis
$ travis encrypt QUAY_OAUTH_TOKEN=`cat ~/tokens/quay-oauth-token` --add
##Local Builds
$ export QUAY_OAUTH_TOKEN=`cat ~/tokens/quay-oauth-token`
For more information on encrypting keys using travis see <https://docs.travis-ci.com/user/encryption-keys/>
- Give involucro your authentication info
Give Involucro a URL with your information.
https://MY_USER:MY_PASSWORD@quay.io/v1/?email=MY_EMAIL
The password can either be a plaintext password or the encrypted password. If
you need to check this run docker login quay.io
with your credentials. Save
it to a plain text file called ~/tokens/involucro-auth .
$ cd my-recipes-repo
##Using Travis
$ travis encrypt INVOLUCRO_AUTH=`cat ~/tokens/involucro-auth` --add
##Local Builds
$ export INVOLUCRO_AUTH=`cat ~/tokens/involucro-auth`
You can also export these variables to your own environment and try it out.
$ cd my-recipes-repo
$ export INVOLUCRO_AUTH=`cat ~/tokens/involucro-auth`
$ export QUAY_OAUTH_TOKEN=`cat ~/tokens/quay-oauth-token`
$ mulled-build build-and-test 'pandoc=1.17.2--0' --test 'pandoc --help' -n MY_QUAY
$ mulled-build push 'pandoc=1.17.2--0' --test 'pandoc --help' -n MY_QUAY
Dependency Resolution¶
galaxy-lib includes a pluggable dependency resolution system that can be used to map software descriptions
(such a Galaxy requirement
tags or CWL tool SoftwareRequirement
annotations) to shell command that
inject these software requirements into a shell job.
This module for dependency resolution has been integrated with:
Dependency resolvers are configured from within a dependency resolvers configuration file (e.g.
dependency_resolvers_conf.yml
). This file can be either XML or YAML and must contain an ordered
list of dependency resolvers to configure.
The dependency resolution system will attempt to walk through each requirement and find the first resolver that matches that requirement. The configuration corresponding to the default Galaxy resolution is discussed here and various CWL examples are worked through in the cwltool README here.
Below some of the command resolvers are discussed in detail and some of their options are described as well but no promise of completeness is made. Please consult the code for the latest options.
The Resolvers¶
Conda Dependency Resolver - conda
¶
The conda
directive can be used to configure a conda dependency resolver.
This resolver can be configured with the following options.
For a very detailed discussion of Conda dependency resolution, check out the Galaxy Conda FAQ.
- prefix
- The conda_prefix used to locate dependencies in (default:
<tool_dependency_dir>/_conda
). - exec
- The conda executable to use, it will default to the one on the
PATH (if available) and then to
<conda_prefix>/bin/conda
. - versionless
- whether to resolve tools using a version string or not (default:
False
). - debug
- Pass debug flag to conda commands (default:
False
). - ensure_channels
- conda channels to enable by default. See
http://conda.pydata.org/docs/custom-channels.html for more
information about channels. This defaults to
iuc,conda-forge,bioconda,defaults
. This order should be consistent with the Bioconda prescribed order if it includesbioconda
. - auto_install
- If
True
, Galaxy will look for and install missing tool dependencies before running a job (default:False
). - auto_init
- If
True
, Galaxy will try to install Conda from the web automatically if it cannot find a local copy andconda_exec
is not configured. This defaults toTrue
as of Galaxy 17.01. - copy_dependencies
- If
True
, Galaxy will copy dependencies over instead of symbolically linking them when creating per job environments. This should be considered somewhat deprecated because Conda will do this as needed for newer versions of Conda - such as the version targeted with Galaxy 17.01+. - mapping_files
- See a discussion of mapping files below.
Galaxy Packages Dependency Resolver - galaxy_packages
¶
The galaxy_packages
dependency resolver allows Galaxy admins to specify how Galaxy should load manually
installed packages. This resolver can be configured either to use the version string or in versionless mode.
The Galaxy Packages dependency resolver takes a base_path
argument that specifies the path under which
it starts looking for the files it requires. The default value for this base_path
is the
tool_dependency_dir
configured in Galaxy’s config/galaxy.ini
. Below the base path, the Galaxy Packages
resolver looks for directories named after tools, e.g. bedtools
. As mentioned before, this resolver
works in versioned and versionless mode. The default mode is versioned, where the dependency resolver looks for a
directory named after the dependency’s version string. For example, if the Galaxy tool specifies that it
needs bedtools
version 2.20.1, the dependency resolver will look for a directory bedtools/2.20.1
.
If the Galaxy Package dependency resolver finds a bin
directory in this directory, it adds it to the PATH
used by the scripts Galaxy uses to run tools. If, however, it finds an env.sh
script, it sources this
script before running the tool that requires this dependency. This can be used to set up the environment
needed for the tool to run.
A simple example might be to assume that a collection of bioinformatics software is manually installed in various
directories under /opt/biosoftware
. In this case a <tool_dependency_dir>/bedtools/2.20.1/env.sh
could be
setup to add the corresponding bedtools installation to the Galaxy tool execution’s PATH
.
#!/bin/sh
export PATH=$PATH:/opt/biosoftware/bedtools/2.20.1/bin
As another example, this env.sh
uses Environment Modules
to setup the environment for bedtools
#!/bin/sh
if [ -z "$MODULEPATH" ] ; then
. /etc/profile.d/module.sh
fi
module add bedtools/bedtools-2.20.1
The Galaxy Package dependency resolver operates quite similarly when used in versionless module. Instead of looking
for a directory named after a version, it looks for a directory symbolic link named default
that links to a
concrete version such as the 2.20.1
example above. For example if bedtools/default
links to bedtools/2.20.1
.
It then looks for a bin subdirectory or env.sh
and incorporates these in the tool script that finally gets run.
This versionless (i.e. default) lookup is also used if the package requirement does not specify a version string.
The mapping_file
parameter on can be set on the dependency resolution directive for the galaxy_packages
dependency resolver. See a discussion of mapping files below for more information.
Environment Modules Dependency Resolver - modules
¶
The example above used Environment Modules to set the PATH
(and other settings) for bedtools
. With
the modules
dependency resolver it is possible to use Environment Modules directory. This resolver
takes these parameters:
- modulecmd
- path to Environment Modules’
modulecmd
tool - modulepath
- value used for MODULEPATH environment variable, used to locate modules
- versionless
- whether to resolve tools using a version string or not (default:
false
) - find_by
- whether to use the
DirectoryModuleChecker
orAvailModuleChecker
(permissable values aredirectory
oravail
, default isavail
) - prefetch
- in the AvailModuleChecker prefetch module info with
module avail
(default:true
) - default_indicator
- what indicate to the AvailModuleChecker that a module is the default version (default:
(default)
). Note that the first module found is considered the default when no version is used by the resolver, so the sort order of modules matters. - mapping_files
- See a discussion of mapping files below.
The Environment Modules dependency resolver can work in two modes. The AvailModuleChecker
searches the results
of the module avail
command for the name of the dependency. If it is configured in versionless mode,
or is looking for a package with no version specified, it accepts any module whose name matches and is a bare word
or the first module whose name matched. For this reason, the default version of the module should be the first one
listed, something that can be achieved by tagging it with a word that appears first in sort order, for example the
string (default)
(yielding a module name like bedtools/(default)
). So when looking for bedtools
in
versionless mode the search would match the first module called bedtools
, and in versioned mode the search would
only match if a module named bedtools/2.20.1
was present (assuming you’re looking for bedtools/2.20.1
).
The``DirectoryModuleChecker`` looks for files or directories in the path specified by MODULEPATH
or
MODULESHOME
that match the dependency being resolved. In versionless mode a match on simply
the dependency name is needed, and in versioned mode a match on the dependency name and
version string is needed.
If a module matches the dependency is found, code to executed modulecmd sh load
with the name of the dependency
is added to the script that is run to run the tool. E.g. modulecmd sh load bedtools
. If version strings are being
used, they’ll be used in the load
command e.g. modulecmd sh load bwa/0.7.10.039ea20639
.
LMOD Dependency Resolver - lmod
¶
The LMOD dependency resolver closely mirrors the environment module dependency resolver but is optimized to target the LMOD module system.
The options available to this dependency resolver include:
- versionless
- whether to resolve tools using a version string or not (default is
false
). - lmodexec
- Path to the lmod executable on your system (default the value of the
LMOD_CMD
environment variable). - settargexec
- Path to the settarg executable on your system (default is the value of the
LMOD_SETTARG_CMD
environment variable) - modulepath
- Path to the folder that contains the LMOD module files on your system (default is the value of the
MODULEPATH
environment variable) - mapping_files
- See a discussion of mapping files below.
The LMOD dependency was implemented in Galaxy Pull Request #4489 by @arbernard.
Tool Shed Dependency Resolver - tool_shed_packages
¶
Unlike the other dependency resolvers described here - this one is likely only useful from within Galaxy.
The tool_shed_packages
dependency resolver works with explicit software packages installed from the Galaxy Tool
Shed as described by legacy tool_dependencies.xml
files. When such a package is installed from the Tool Shed it
creates a directory structure under the directory that is specified as the tool_dependency_dir
in Galaxy’s
configuration. This directory structure contains references to the tool’s ID, owner (in the Tool Shed) and version
string (amongst other things) and ultimately contains a file named env.sh
that contains commands to make the
dependency runnable. This is installed, along with the packaged tool, by the tool package and doesn’t require any
configuration by the Galaxy administrator.
Tools installed from the Tool Shed may also install Conda recipes and most new best practice tools do this by default now.
The Tool Shed dependency resolver is not able to resolve package requirements that do not have a version string, like the bedtools example above.
Homebrew Dependency Resolver - homebrew
¶
This dependency resolver uses homebrew packages to resolve requirements. It is highly experimental and undocumented.
Brew Tool Shed Package Resolver - shed_tap
¶
This dependency resolver would resolve tool shed packages that had been auto converted to the tool shed. It is highly experimental, undocumented, and will almost certainy be removed from the code base.
Mapping Files¶
A few different dependency resolvers allow specification of a mapping_files
parameter. If specified,
these files describe rules to rewrite the abstract requirements from tools to locally available values on either
the system or in a known package source such as Bioconda. Check out Galaxy Pull Request #3444 and Pull Request #3509 for implementation details.
The format of the mapping files is simple a YAML file with a flat list of “rules”. Each rule should specify a
from
condition describing the abstract requirements to map and a to
value that describes how the requirement
should be rewritten.
Consider the following CWL SoftwareRequirement
and Galaxy requirement
:
hints:
SoftwareRequirement:
packages:
- package: 'random-lines'
version:
- '1.0'
<requirement type="package" version="1.0">random-lines</requirement>
Now imaging some galaxy_package
or environment Module named randomLines
fullfills this requirement and
is configured with a version of 1.0.0-rc1
. The following mapping rule would allow redirecting the corresponding
resolver to target that package:
- from:
name: randomLines
version: 1.0.0-rc1
to:
name: random-lines
version: '1.0'
If no version
is specified, all versions will be targetted and the from
value can simply the requirement name
instead of a dictionary. To just target requirements without specified versions set unversioned: true
in the requirement rule. For instance:
- from:
name: package
unversioned: true
to:
name: package
version: 1.3.1
By default, Galaxy (not galaxy-lib) configures some mappings from Conda in the file default_conda_mapping.yml
Here are some examples from that file:
- from: R
to: r-base
- from: blast+
to: blast
- from:
name: samtools
unversioned: true
to:
name: samtools
version: 1.3.1
- from:
name: ucsc_tools
unversioned: true
to:
name: ucsc_tools
version: 332
- from:
name: bedtools
unversioned: true
to:
name: bedtools
version: 2.26.0gx
Galaxy also sets up some default mapping files for both the conda
and lmod
dependency resolvers if the
files config/local_conda_mapping.yml
or config/lmod_modules_mapping.yml
respectively are present in Galaxy.
Release Checklist¶
This page describes the process of releasing new versions of galaxy-lib.
This release checklist is based on the Pocoo Release Management Workflow.
This assumes ~/.pypirc
file exists with the following fields (variations)
are fine.
[distutils]
index-servers =
pypi
test
[pypi]
username:<username>
password:<password>
[test]
repository:https://testpypi.python.org/pypi
username:<username>
password:<password>
Review
git status
for missing files.Verify the latest Travis CI builds pass.
make open-docs
and review changelog.Ensure the target release is set correctly in
galaxy/__init__.py
(version
will be adevN
variant of target release).make clean && make lint && make test
make release
This process will push packages to test PyPI, allow review, publish to production PyPI, tag the git repository, push the tag upstream, and modify the Homebrew recipe. If changes are needed, such as manual changes to the homebrew recipe, this can be broken down into steps such as:
make release-local
make push-release
make release-brew
History¶
18.9.2.dev0¶
18.9.1 (2018-09-15)¶
- More work improving channel handling for mulled containers.
18.9.0 (2018-09-14)¶
- Update Conda channel order (thanks to @bgruening).
- Bring in the latest Galaxy changes and add Galaxy XSD to the project.
- Various cwltool fixes (thanks to @nsoranzo).
18.5.15 (2018-09-12)¶
- More tweaks to CWL tool loading to support newer versions of cwltool.
18.5.14 (2018-09-12)¶
- Improved tool linting and reporting thanks to @natefoo and @nsoranzo.
- Add support for newer cwltool thanks to @nsoranzo.
- Improved mulled building thanks to @pcm32.
18.5.13 (2018-05-23)¶
- Small updates to test parsing to support Galaxy workflow testing.
18.5.12 (2018-05-22)¶
- Update test data processing to allow URIs in Galaxy workflow tests.
18.5.11 (2018-05-16)¶
- Parse CWL SoftwareRequirements to Galaxy requirements (required to fix various Planemo functionality for CWL tools).
18.5.10 (2018-05-10)¶
- Docker logging API fix for Planemo.
18.5.9 (2018-05-07)¶
- Update CWL linting to target CWL 1.0.
18.5.8 (2018-05-06)¶
- Better error handling for Conda searching (thanks to @bgruening).
- Update against the latest Galaxy codebase.
- Add Galaxy tool linting to ensure versions are PEP 440 compliant (thanks to @davebx).
18.5.7 (2018-03-12)¶
- More tool testing client fixes, this time for ephemeris.
18.5.6 (2018-03-12)¶
- Bring in the latest Galaxy dev branch - includes code cleanup and many Python 3 fixes from @nsoranzo as well as client code for executing tool tests against external Galaxy instances.
- Extend tool testing client from Galaxy’s dev branch with even more data collection for compatiblity with Planemo.
18.5.5 (2018-03-06)¶
- Fix mulled to use shlex.quote to escape single quotes in test command (thanks to @mbargull).
- Make markupsafe a dependency since it is import unconditionally in galaxy.tools.toolbox (thanks to @mbargull).
- Python 3 fix for assertion testing.
18.5.4 (2018-03-01)¶
- Make conda image for mulled builds configurable via an environment variable (thanks to @mbargull).
18.5.3 (2018-02-28)¶
- Fix path module for import on Windows for Pulsar.
18.5.2 (2018-02-28)¶
- Various fixes for library usage mostly related to Conda (with help from @nsoranzo).
18.5.1 (2018-02-26)¶
- Redo last release - pushed to PyPI without actually including the desired fix.
18.5.0 (2018-02-26)¶
- Another Python 3 fix for Planemo.
- Fix galaxy-lib version - this has actually been tracking the 18.05 release of Galaxy for the last two releases.
18.1.0 (2018-02-26)¶
- More Python 3 fixes for Planemo thanks to @nsoranzo.
- Bring in the latest Galaxy development branch.
17.9.12 (2018-02-22)¶
- Python 3 fix for Planemo thanks to @nsoranzo.
- Fix bad merge of miniconda update for mulled work.
17.9.11 (2018-02-22)¶
- Update to the latest Galaxy dev just prior to the branch of 18.01.
- Python 3 fixes.
17.9.10 (2017-11-23)¶
- Added docs for using mulled-build with your own quay.io account (thanks to @jerowe).
- Catch errors in Conda search if nothing is found (preventing planemo-monitor from functioning properly) (thanks to @bgruening).
- Make multi-requirement container building via mulled more stable (thanks to @bgruening).
17.9.9 (2017-09-27)¶
- Bring in latest updates from the 17.09 branch of Galaxy - including updating the default target Conda version and fixes for module resolution.
17.9.8 (2017-09-26)¶
- Bring in updated CWL utilities from the upstream work on CWL integration.
17.9.7 (2017-09-19)¶
- Bring in updated CWL utilities from the upstream work on CWL integration.
17.9.6 (2017-09-15)¶
- Remove
command
lint check that is no longer valid.
17.9.5 (2017-09-06)¶
- Bring in updated CWL utilities from the upstream work on CWL integration.
17.9.4 (2017-09-06)¶
- Bring in various Galaxy updates including numerous Conda fixes and changes (thanks to @nsoranzo).
- Improved error handling when parsing tool reStructuredText (thanks to @erasche).
- Updated CWL utilities.
17.9.3 (2017-06-27)¶
- Bug fix in from_dict parsing of tool dependency specs.
17.9.2 (2017-06-22)¶
- Sync with mulled enhancements and fixes from Galaxy’s development branch.
17.9.1 (2017-06-17)¶
- Various small Singularity fixes and enhancements.
17.9.0 (2017-06-11)¶
- Bring in latest Galaxy dev changes.
- Implement support for building Singularity mulled containers.
- Implement mulled version 2 package hashing.
- Fix default namespace for mulled operations from mulled to biocontainers.
17.5.11 (2017-05-31)¶
- Fix HISTORY.rst formatting to properly render release on PyPI.
- Fix bug in new offline Conda search function introduced in 17.5.10.
17.5.10 (2017-05-30)¶
- Always clean up build directory in mulled commands (thanks to @johanneskoester).
- Expose offline mode in Conda search utility (for repeated fast searches).
- When publishing mulled containers - use quay.io API to publish them as public.
- Add explicit option
--check-published
tomulled-build-*
. - Fix auto-installation of Involucro on first attempt.
- Handle explicit tags in
mulled-build-files
and add an implicit tag of0
if none found. - Fix tab parsing in
mulled-build-files
.
17.5.9 (2017-05-16)¶
- Make mulled-search to search biocontainers instead of mulled repository by default (thanks to @tom-tan).
- Allow setting a new base image with mulled-build.
17.5.8 (2017-04-23)¶
- Fix mulled image cleanup. #55.
17.5.7 (2017-03-15)¶
- Updates to CWL library functionality for several months worth of CWL tool updates.
- Allow finding tools by a URI-like strings (e.g.
file://
,http://
,dockstore://
). - Bring in latest Galaxy updates.
17.5.6 (2017-03-01)¶
- Expanded options for mulled CLI tools and library functionality. Fixes #49.
17.5.5 (2017-02-26)¶
- Fix bug in 17.5.4 where under certain conditions conda-build would attempt to be setup with the conda –use-local flag - which is not allowed.
17.5.4 (2017-02-26)¶
- Fix local builds Conda support to reflect conda-build is required.
- Fix default target path for miniconda installs.
17.5.3 (2017-02-24)¶
- Update against the latest Galaxy dev branch changes.
- Update Conda utilities to allow using locally built packages.
17.5.2 (2017-02-21)¶
- Conda utility enhancements to fix a Planemo bug.
17.5.1 (2017-02-21)¶
- Various improvements to Galaxy tool linting.
17.5.0 (2017-02-16)¶
- Bring in the last of the Galaxy dev changes.
- Allow Conda installs to target global Conda config (for Planemo)
17.1.2 (2017-01-23)¶
- Bring in the last of the Galaxy dev changes before branch of release_17.01.
- Improvements to mulled testing thanks to @mvdbeek.
17.1.1 (2016-12-14)¶
- Revert changes to shell command execution in Galaxy that had unintended consequences for Planemo.
17.1.0 (2016-12-12)¶
- Improved mulled logging thanks to @bgruening.
- Bring in the latest Galaxy dev changes.
16.10.10 (2016-10-24)¶
- Fix mulled package data fetching for Mac OS X (thanks to @dannon).
16.10.9 (2016-10-21)¶
- Small fixes including to reflect mulled name on quay.io changed to biocontainers.
16.10.8 (2016-10-10)¶
- More mulled enhancements and bug fixes thanks to @bgruening and @daler.
16.10.7 (2016-10-08)¶
- More mulled enhancements and bug fixes thanks to @bgruening.
- Fix bioconda support by adding conda-forge to list of default channels.
16.10.6 (2016-10-07)¶
- More mulled enhancements thanks to @bgruening.
16.10.5 (2016-10-04)¶
- Some docstring cleanup and minor tweaks to Conda support for downstream planemo mulled work.
16.10.4 (2016-10-03)¶
- More mulled fixes and enhancements.
16.10.3 (2016-10-02)¶
- Small mulled and Conda related fix and enhancements.
16.10.2 (2016-09-30)¶
- Fix setup.py for features in 16.10.1.
16.10.1 (2016-09-29)¶
- Updates for recents changes to Galaxy and initial mulled scripts and container resolver.
16.10.0 (2016-08-31)¶
- Updates for recent changes to Galaxy.
16.7.10 (2016-08-04)¶
- Updates for recent change to Galaxy.
16.7.9 (2016-06-13)¶
- Updates for recent changes to Galaxy and cwltool.
16.7.8 (2016-06-05)¶
- Updates to include Galaxy library for verifying test outputs and the latest dev changes to Galaxy.
16.7.7 (2016-05-23)¶
- Fixes to CWL and Docker libraries for Planemo.
16.7.6 (2016-05-11)¶
- Fixes to cwl processing for Planemo.
16.7.5 (2016-05-11)¶
- Updates to cwl processing for Planemo.
16.7.4 (2016-05-10)¶
- Updates to cwl processing for Planemo.
16.7.3 (2016-05-07)¶
- Updates to cwltool_deps for Planemo.
16.7.2 (2016-05-06)¶
- Updates to tool parsing and linting for Planemo.
16.7.1 (2016-05-02)¶
- Update against the latest development branch of Galaxy.
16.7.0 (2016-04-21)¶
- Update against the latest development branch of Galaxy.
16.4.1 (2016-04-08)¶
- Update against the latest development branch of Galaxy.
16.4.0 (2016-02-15)¶
- Update against the latest development branch of Galaxy.
16.1.9 (2016-01-14)¶
- Fix a bug in the source distribution of galaxy-lib.
16.1.8 (2016-01-12)¶
- Update against Galaxy’s release_16.01 branch.
16.1.7 (2016-01-03)¶
- Update against Galaxy’s dev branch - including conda updates, dependency resolution changes, and toolbox updates.
16.1.6 (2015-12-28)¶
- Additional fixes to setup.py and updates for recent changes to Galaxy’s dev branch.
16.1.5 (2015-12-22)¶
- Fix another bug that was preventing dependency resolution from working in Pulsar.
16.1.4 (2015-12-22)¶
- Another setup.py fix for job metrics module.
16.1.3 (2015-12-22)¶
- Python 3 fixes and updates for recent Galaxy dev commits.
16.1.2 (2015-12-21)¶
- Fix for missing galaxy.tools.parser package in setup.py.
- Fix LICENSE in repository.
16.1.1 (2015-12-20)¶
- Fix small issues with dependencies, naming, and versioning with first release.
16.1.0 (2015-12-20)¶
- Setup project.