.travis.yml

@@ -3,6 +3,7 @@
 sudo: false
 language: python
 env:
+  - PYTHON_VERSION=3.6 MAKE_DOC=TRUE
   - PYTHON_VERSION=3.5 MAKE_DOC=TRUE
   - PYTHON_VERSION=3.4 USE_CYTHON=TRUE
 before_install:
@@ -15,9 +16,12 @@ before_install:
   # Update conda itself
   - conda update --yes conda
 install:
-  - conda create --yes -n env_name python=$PYTHON_VERSION --file ci/conda_requirements.txt
+  - conda create --yes -n env_name python=$PYTHON_VERSION
+  - conda install --yes -n env_name --file ci/conda_requirements.txt
   - if [ ${USE_CYTHON} ]; then conda install --yes -n env_name cython; fi
   - source activate env_name
+  - conda info --envs
+  - python --version
   - pip install -r ci/pip_requirements.txt
   - pip install . --no-deps
 script:

CHANGELOG.md

 # scikit-bio changelog
 
+## Version 0.5.2 (2018-04-18)
+
+### Features
+* Added ``skbio.io.format.embl`` for reading and writing EMBL files for ``DNA``, ``RNA`` and ``Sequence`` classes.
+
+* Removing ValueError check in `skbio.stats._subsample.subsample_counts` when `replace=True` and `n` is greater than the number of items in counts.  [#1527](https://github.com/biocore/scikit-bio/pull/1527)
+
+* Added ``skbio.io.format.gff3`` for reading and writing GFF3 files for ``DNA``, ``Sequence``, and ``IntervalMetadata`` classes. ([#1450](https://github.com/biocore/scikit-bio/pull/1450))
+
+* `skbio.metadata.IntervalMetadata` constructor has a new keyword argument, `copy_from`, for creating an `IntervalMetadata` object from an existing `IntervalMetadata` object with specified `upper_bound`.
+
+* `skbio.metadata.IntervalMetadata` constructor allows `None` as a valid value for `upper_bound`. An `upper_bound` of `None` means that the `IntervalMetadata` object has no upper bound.
+
+* `skbio.metadata.IntervalMetadata.drop` has a new boolean parameter `negate` to indicate whether to drop or keep the specified `Interval` objects.
+
+### Backward-incompatible changes [stable]
+
+### Backward-incompatible changes [experimental]
+
+### Performance enhancements
+* `skbio.tree.nj` wall-clock runtime was decreased by 99% for a 500x500 distance matrix and 93% for a 100x100 distance matrix. ([#1512](https://github.com/biocore/scikit-bio/pull/1512), [#1513](https://github.com/biocore/scikit-bio/pull/1513))
+
+### Bug fixes
+* The `include_self` parameter was not being honored in `skbio.TreeNode.tips`. The scope of this bug was that if `TreeNode.tips` was called on a tip, it would always result in an empty `list` when unrolled.
+
+* In `skbio.stats.ordination.ca`, `proportion_explained` was missing in the returned `OrdinationResults` object. ([#1345](https://github.com/biocore/scikit-bio/issues/1345))
+
+* `skbio.diversity.beta_diversity` now handles qualitative metrics as expected such that `beta_diversity('jaccard', mat) == beta_diversity('jaccard', mat > 0)`. Please see [#1549](https://github.com/biocore/scikit-bio/issues/1549) for further detail.
+
+* `skbio.stats.ordination.rda` The occasional column mismatch in output `biplot_scores` is fixed ([#1519](https://github.com/biocore/scikit-bio/issues/1519)).
+
+### Deprecated functionality [stable]
+
+### Deprecated functionality [experimental]
+
+### Miscellaneous
+* scikit-bio now depends on pandas >= 0.19.2, and is compatible with newer pandas versions (e.g. 0.20.3) that were previously incompatible.
+* scikit-bio now depends on `numpy >= 1.9.2, < 1.14.0` for compatibility with Python 3.4, 3.5, and 3.6 and the available numpy conda packages in `defaults` and `conda-forge` channels.
+* added support for running tests from `setup.py`. Both `python setup.py nosetests` and `python setup.py test` are now supported, however `python setup.py test` will only run a subset of the full test suite. ([#1341](https://github.com/biocore/scikit-bio/issues/1341))
+
 ## Version 0.5.1 (2016-11-12)
 
 ### Features
@@ -12,6 +52,7 @@
 * ``DistanceMatrix`` now has a new method called ``to_series`` to create a ``pandas.Series`` from a ``DistanceMatrix`` ([#1397](https://github.com/biocore/scikit-bio/issues/1397)).
 * Added parallel beta diversity calculation support via `skbio.diversity.block_beta_diversity`. The issue and idea is discussed in ([#1181](https://github.com/biocore/scikit-bio/issues/1181), while the actual code changes are in [#1352](https://github.com/biocore/scikit-bio/pull/1352)).
 
+
 ### Backward-incompatible changes [stable]
 * The constructor API for `Sequence` and its child classes (including `GrammaredSequence`, `RNA`, `DNA`, `Protein`) are changed from `(sequence, metadata=None, positional_metadata=None, lowercase=False)` to `(sequence, metadata=None, positional_metadata=None, interval_metadata=None, lowercase=False)`
 

CONTRIBUTING.md

@@ -179,7 +179,7 @@ All code that is added to scikit-bio must be unit tested, and the unit test code
 
 Running ``make test`` locally during development will include a subset of the full checks performed by Travis-CI.
 
-The scikit-bio coding guidelines describe our [expectations for unit tests](http://scikit-bio.org/development/coding_guidelines.html). You should review the unit test section before working on your test code.
+The scikit-bio coding guidelines describe our [expectations for unit tests](http://scikit-bio.org/docs/latest/development/coding_guidelines.html). You should review the unit test section before working on your test code.
 
 Tests can be executed by running ``make test`` from the base directory of the project or from within a Python or IPython session:
 

MANIFEST.in

@@ -3,8 +3,10 @@ include CHANGELOG.md
 include CONTRIBUTING.md
 include COPYING.txt
 include Makefile
+include PULL_REQUEST_TEMPLATE.md
 include README.rst
 include RELEASE.md
+include REVIEWING.md
 include checklist.py
 include asv.conf.json
 

PULL_REQUEST_TEMPLATE.md

+Please complete the following checklist:
+
+* [ ] I have read the guidelines in [CONTRIBUTING.md](https://github.com/biocore/scikit-bio/blob/master/CONTRIBUTING.md).
+
+* [ ] I have documented all public-facing changes in [CHANGELOG.md](https://github.com/biocore/scikit-bio/blob/master/CHANGELOG.md).
+
+* [ ] **This pull request includes code, documentation, or other content derived from external source(s).** If this is the case, ensure the external source's license is compatible with scikit-bio's [license](https://github.com/biocore/scikit-bio/blob/master/COPYING.txt). Include the license in the `licenses` directory and add a comment in the code giving proper attribution. Ensure any other requirements set forth by the license and/or author are satisfied. **It is your responsibility to disclose code, documentation, or other content derived from external source(s).** If you have questions about whether something can be included in the project or how to give proper attribution, include those questions in your pull request and a reviewer will assist you.
+
+* [ ] **This pull request does not include code, documentation, or other content derived from external source(s).**
+
+**Note:** [REVIEWING.md](https://github.com/biocore/scikit-bio/blob/master/REVIEWING.md) may also be helpful to see some of the things code reviewers will be verifying when reviewing your pull request.

README.rst

@@ -21,7 +21,7 @@ The recommended way to install scikit-bio is via the ``conda`` package manager a
 
 To install the latest release of scikit-bio::
 
-    conda install -c https://conda.anaconda.org/biocore scikit-bio
+    conda install -c conda-forge scikit-bio
 
 Alternatively, you can install scikit-bio using ``pip``::
 
@@ -118,13 +118,13 @@ scikit-bio's logo was created by `Alina Prassas <http://cargocollective.com/alin
    :target: https://gitter.im/biocore/scikit-bio?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge
 .. |Depsy Badge| image:: http://depsy.org/api/package/pypi/scikit-bio/badge.svg
    :target: http://depsy.org/package/python/scikit-bio
-.. |Anaconda Cloud Build| image:: https://anaconda.org/biocore/scikit-bio/badges/build.svg
+.. |Anaconda Cloud Build| image:: https://anaconda.org/conda-forge/scikit-bio/badges/build.svg
    :target: https://anaconda.org/biocore/scikit-bio/builds
-.. |Anaconda Cloud| image:: https://anaconda.org/biocore/scikit-bio/badges/version.svg
-   :target: https://anaconda.org/biocore/scikit-bio
-.. |License| image:: https://anaconda.org/biocore/scikit-bio/badges/license.svg
-   :target: https://anaconda.org/biocore/scikit-bio
-.. |Downloads| image:: https://anaconda.org/biocore/scikit-bio/badges/downloads.svg
-   :target: https://anaconda.org/biocore/scikit-bio
-.. |Install| image:: https://anaconda.org/biocore/scikit-bio/badges/installer/conda.svg
-   :target: https://conda.anaconda.org/biocore
+.. |Anaconda Cloud| image:: https://anaconda.org/conda-forge/scikit-bio/badges/version.svg
+   :target: https://anaconda.org/conda-forge/scikit-bio
+.. |License| image:: https://anaconda.org/conda-forge/scikit-bio/badges/license.svg
+   :target: https://anaconda.org/conda-forge/scikit-bio
+.. |Downloads| image:: https://anaconda.org/conda-forge/scikit-bio/badges/downloads.svg
+   :target: https://anaconda.org/conda-forge/scikit-bio
+.. |Install| image:: https://anaconda.org/conda-forge/scikit-bio/badges/installer/conda.svg
+   :target: https://conda.anaconda.org/conda-forge

RELEASE.md

@@ -2,29 +2,31 @@
 
 ## Introduction
 
-This guide explains how to release a new version of scikit-bio. To illustrate examples of commands you might run, let's assume that the current version is 1.2.3-dev and we want to release version 1.2.4. Our versioning system is based on Semantic Versioning, which you can read about at http://semver.org.
+This guide explains how to release a new version of scikit-bio. To illustrate examples of commands you might run, let's assume that the current version is x.y.y-dev and we want to release version x.y.z.
 
-**Note:** The following commands assume you are in the top-level directory of the scikit-bio repository unless otherwise noted. They also assume that you have [virtualenv](http://virtualenv.readthedocs.org/en/latest/#)/[virtualenvwrapper](http://virtualenvwrapper.readthedocs.org/en/latest/) installed.
+**Note:** The following commands assume you are in the top-level directory of the scikit-bio repository unless otherwise noted. They also assume that you have [Miniconda3](http://conda.pydata.org/miniconda.html) installed. It is important that you use Miniconda3, and not Miniconda2, because the root `conda` environment needs Python 3 for the build steps below.
 
-**Tip:** It can be efficient to have the help of a couple other devs, as some steps can be run in parallel. It's also useful to have a variety of platforms/environments to test on during the release process, so find friends that are Linux and Mac users!
-
-## Prep the release (part 1)
+## Prep the release
 
 1. Ensure the Travis build is passing against master.
 
-2. Update the version strings (1.2.3-dev) to the new version (1.2.4). There should only be one place this needs to be done: ``skbio/__init__.py``. It's a good idea to ``grep`` for the current version string just to be safe:
+2. Update the version strings (x.y.y-dev) to the new version (x.y.z). This will include `__version__` defined in ``skbio/__init__.py``, as well as any `@experimental/@stable/@deprecated` [API stability decorators](http://scikit-bio.org/docs/latest/user/api_stability.html) with `as_of='x.y.y-dev'`. ``grep`` for the current version string to find all occurrences:
+
+        grep -r 'x\.y\.y-dev' .
+
+3. Remove any deprecated functionality that was scheduled for removal on or before this release. When removing deprecated functionality, make sure the functionality has been in a deprecated state for the appropriate number of releases described in the [API stability docs](http://scikit-bio.org/docs/latest/user/api_stability.html). If there is functionality that shouldn't be removed yet, bump the `until` version to a future version. To find all deprecated functionality, search for `@deprecated` decorators:
 
-        grep -ir '1\.2\.3-dev' *
+        grep -r '@deprecated' .
 
-3. Update ``CHANGELOG.md`` to include descriptions of the changes that made it into this release. Be sure to update the heading to include the new version (1.2.4) and the date of the release. Use the existing structure in the file as a template/guide.
+    Note any deprecated functionality that was removed in the `### Miscellaneous` section of `CHANGELOG.md`.
 
-4. Submit a pull request with these changes and let Travis run.
+4. Update ``CHANGELOG.md`` to include descriptions of all **user-facing** changes that made it into this release. Be sure to update the heading to include the new version (x.y.z) and the date of the release. Use the existing structure in the file as a template/guide.
 
-## Build the documentation
+5. Submit a pull request and merge when Travis-CI tests are passing.
 
-In the meantime, you can build the documentation and update the website.
+## Build website docs
 
-**Note:** You will need to **fully install** (including built extensions) the exact version of scikit-bio that you are editing so that Sphinx will pull docstrings from the correct version of the code. **Make sure the version of scikit-bio that is imported by ``import skbio`` is the correct one!**
+You will need to **fully install** the latest master branch of scikit-bio (including built extensions) and build the docs from this version. **Make sure the version of scikit-bio that is imported by ``import skbio`` is the correct one before building the docs.**
 
 1. Build the documentation locally:
 
@@ -32,51 +34,42 @@ In the meantime, you can build the documentation and update the website.
 
 2. Switch to the ``gh-pages`` branch of the repository.
 
-3. Remove everything from ``docs/latest/``:
+3. Remove ``docs/latest``:
 
-        git rm -rf docs/latest/*
+        git rm -rf docs/latest
 
-4. Create a directory for the new version of the docs and recreate the ``latest/`` directory:
+4. Copy over the built documentation to ``docs/x.y.z`` and ``docs/latest``:
 
-        mkdir docs/1.2.4
-        mkdir docs/latest
+        cp -r doc/build/html docs/latest
+        cp -r doc/build/html docs/x.y.z
 
-5. Copy over the built documentation to both ``docs/1.2.4/`` and ``docs/latest``:
+5. Add a new list item to ``index.html`` to link to ``docs/x.y.z/index.html``.
 
-        cp -r <path to skbio repo>/doc/build/html/* docs/1.2.4/
-        cp -r <path to skbio repo>/doc/build/html/* docs/latest/
-
-6. Add a new list item to ``index.html`` to link to ``docs/1.2.4/index.html``.
+6. Port content from ``README.md`` to ``index.html`` if there are any changes that need to be included on the front page.
 
 7. Test out your changes by opening the site locally in a browser. Be sure to check the error console for any errors.
 
-8. Commit and push (either directly or as a pull request) to have the website updated. **Note:** This updates the live website, so be sure to poke through the live site to make sure things aren't broken and that version strings are correct.
-
-## Prep the release (part 2)
-
-If the tests passed on Travis (see step 4 of **Prep the release (part 1)** above), merge the pull request to update the version strings to 1.2.4.
+8. Submit a pull request with the website updates and merge. **Note:** Once merged, the live website is updated, so be sure to poke through the live site to make sure things are rendered correctly with the right version strings.
 
 ## Tag the release
 
-From the [scikit-bio GitHub page](https://github.com/biocore/scikit-bio), click on the releases tab and draft a new release. Use the version number for the tag name (1.2.4) and create the tag against master. Fill in a release title that is consistent with previous release titles and add a summary of the release (linking to ``CHANGELOG.md`` is a good idea). This release summary will be the primary information that we point users to when we announce the release.
+From the [scikit-bio GitHub page](https://github.com/biocore/scikit-bio), click on the releases tab and draft a new release. Use the version number for the tag name (x.y.z) and create the tag against master. Fill in a release title that is consistent with previous release titles and add a summary of the release (linking to ``CHANGELOG.md`` is a good idea). This release summary will be the primary information that we point users to when we announce the release.
 
 Once the release is created on GitHub, it's a good idea to test out the release tarball before publishing to PyPI:
 
-1. Create a new virtualenv.
+1. Create a new `conda` environment for testing (fill in a name for `<environment>`):
 
-2. Download the release tarball from GitHub, extract it, and ``cd`` into the top-level directory.
+        conda create -n <environment> python=3.5 numpy
+        source activate <environment>
 
-3. Install the release and run the tests:
+2. Install the release tarball from GitHub and run the tests:
 
-        pip install .
-        cd
+        pip install https://github.com/biocore/scikit-bio/archive/x.y.z.tar.gz
         python -m skbio.test
 
-4. During this process (it can take awhile to install all of scikit-bio's dependencies), submit a pull request to update the version strings from 1.2.4 to 1.2.4-dev. Use the same strategy described above to update the version strings. Update ``CHANGELOG.md`` to include a new section for 1.2.4-dev (there won't be any changes to note here yet). **Do not merge this pull request yet.**
-
-## Test the source distribution
+## Publish the release
 
-Assuming the GitHub release tarball correctly installs and passes its tests, you're now ready to test the creation of the source distribution (``sdist``) that will be published to PyPI. It is important to test the source distribution because it is created in an entirely different way than the release tarball on GitHub. Thus, there is the danger of having two different release tarballs: the one created on GitHub and the one uploaded to PyPI.
+Assuming the GitHub release tarball correctly installs and passes its tests, you're ready to create the source distribution (``sdist``) that will be published to PyPI. It is important to test the source distribution because it is created in an entirely different way than the release tarball on GitHub. Thus, there is the danger of having two different release tarballs: the one created on GitHub and the one uploaded to PyPI.
 
 1. Download the release tarball from GitHub, extract it, and ``cd`` into the top-level directory.
 
@@ -84,10 +77,10 @@ Assuming the GitHub release tarball correctly installs and passes its tests, you
 
         python setup.py sdist
 
-3. Create a new virtualenv and run:
+3. Create and activate a new `conda` environment, and test the `sdist`:
 
-        cd
-        pip install <path to extracted scikit-bio release>/dist/scikit-bio-1.2.4.tar.gz
+        pip install dist/scikit-bio-x.y.z.tar.gz
+        cd  # cd somewhere outside the extracted scikit-bio directory
         python -m skbio.test
 
 4. If everything goes well, it is finally time to push the release to PyPI:
@@ -96,13 +89,13 @@ Assuming the GitHub release tarball correctly installs and passes its tests, you
 
     You must have the proper login credentials to add a release to PyPI. Currently [@gregcaporaso](https://github.com/gregcaporaso) has these, but they can be shared with other release managers.
 
-5. Once the release is available on PyPI, do a final round of testing. Create a new virtualenv and run:
+5. Once the release is available on PyPI, do a final round of testing. Create a new `conda` environment and run:
 
-        cd
         pip install scikit-bio
+        cd  # cd somewhere outside the extracted scikit-bio directory
         python -m skbio.test
 
-    If this succeeds, the pypi release appears to be a success.
+    If this succeeds, the PyPI release appears to be a success. Make sure the installed version is the correct one.
 
 6. Next, we'll prepare and post the release to [anaconda.org](http://www.anaconda.org).
 
@@ -116,6 +109,13 @@ Assuming the GitHub release tarball correctly installs and passes its tests, you
         conda build scikit-bio --python 3.4
         conda build scikit-bio --python 3.5
 
+    **Note:** When building 64-bit Linux packages, it is recommended that you use conda-forge's `linux-anvil` Docker image. This ensures a consistent Linux build environment that has an old enough version of `libc` to be compatible on most Linux systems. To start up a `linux-anvil` Docker container:
+
+        docker run -i -t condaforge/linux-anvil
+        # Now you should be in the linux-anvil environment
+        sed -i '/conda-forge/d' ~/.condarc
+        # Run the build commands from above
+
     At this stage you have built Python 3.4 and 3.5 packages. The absolute path to the packages will be provided as output from each ``conda build`` commands. You should now create conda environments for each, and run the tests as described above. You can install these local packages as follows:
 
         conda install --use-local scikit-bio
@@ -132,12 +132,12 @@ Assuming the GitHub release tarball correctly installs and passes its tests, you
 
 ## Post-release cleanup
 
-1. Merge the latest pull request to update version strings to 1.2.4-dev.
+1. Submit and merge a pull request to update the version strings from x.y.z to x.y.z-dev (`skbio.__version__` should be the only thing needing an update). Update ``CHANGELOG.md`` to include a new section for x.y.z-dev (there won't be any changes to note here yet).
 
-2. Close the release milestone on the GitHub issue tracker.
+2. Close the release milestone on the GitHub issue tracker if there was one.
 
-3. Send an email to the skbio users and developers lists, and anyone else who might be interested (e.g., lab mailing lists). You might include links to the GitHub release page and ``CHANGELOG.md``.
+3. Send an email to the skbio developers list and anyone else who might be interested (e.g., lab mailing lists). You might include links to the GitHub release page.
 
-4. Tweet about the release, including a link to the GitHub release page (for example, for 0.1.3, the URL to include was https://github.com/biocore/scikit-bio/releases/tag/0.1.3).
+4. Tweet about the release from `@scikit-bio`, including a link to the GitHub release page (for example, https://github.com/biocore/scikit-bio/releases/tag/x.y.z). Post a similar message to [scikit-bio's Gitter](https://gitter.im/biocore/scikit-bio).
 
 5. :beers:

REVIEWING.md

+# Reviewing pull requests
+
+This document provides a high-level, general, and **incomplete** checklist of things that pull request reviewers should be aware of when performing code review. These are guidelines which generally make sense to follow, but they are not intended to be rigid. The checklist mainly consists of things that are specific to the scikit-bio project and that generally apply to incoming pull requests. The checklist is incomplete because it is not possible to describe all things to verify during code review (that depends on what is being reviewed). This document also doesn't attempt to describe *how* to perform code review (there are many online resources for that).
+
+Reviewers are encouraged to keep this document up-to-date as the project evolves and to add anything that's missing.
+
+The checklist is not in any particular order.
+
+## Licensing and attribution
+
+Verify that code being included from external sources has a compatible license and is properly attributed:
+
+- Include the code's license in the top-level `licenses` directory.
+- Include a comment with the external code giving attribution and noting the license in the `licenses` directory.
+- Any other requirements set by the code's license and/or author.
+
+## Changelog
+
+This is one of the most important points to remember as users will review the changelog to identify changes relevant to them. This is one of the easiest parts to forget in a pull request.
+
+- Note all public (i.e. user-facing) changes in `CHANGELOG.md` under the latest development version section at the top of the file. This includes things like bug fixes, API additions/changes/removal, performance enhancements, etc. The changelog has several subsections for organizing these changes.
+- If a corresponding issue exists, it should be linked to from the changelog.
+- Use public imports (`skbio.sequence.Sequence` instead of `skbio.sequence._sequence.Sequence`) when documenting import paths in the changelog.
+- Internal changes not visible/applicable to users (e.g. refactoring, private methods, etc.) are better suited for commit messages than the changelog.
+
+## Public vs. private API
+
+Be aware of what type of API changes are being made. scikit-bio uses the following conventions to distinguish public vs. private API:
+
+**Public API:** API with an import path that doesn't contain leading underscores in any submodule/subpackage/object names. Users and scikit-bio devs can use public API. Example: `skbio.sequence.Sequence`, `skbio.stats.subsample`
+
+**Package-private API:** API with an import path containing a leading underscore in at least one submodule/subpackage. Users should not import package-private API. Package-private API can be imported anywhere *within* the scikit-bio package. Example: `skbio.util._misc.chunk_str`, `skbio.util._testing.ReallyEqualMixin`
+
+**Private API:** API with object name starting with an underscore. Users should not import private API. Private API should only be imported and used in the module where it is defined. It should not be imported in other parts of the scikit-bio package. Example: `skbio.util._testing._normalize_signs`, `skbio.stats.composition._gram_schmidt_basis`
+
+- Prefer defining private APIs and only promote things to the public API that users need access to.
+- Private/package-private API does not need to be decorated with `@experimental`/`@stable`/`@deprecated`, only public API.
+- Within scikit-bio, prefer *using* public APIs defined in the package even if private APIs offer the same functionality.
+
+## API stability
+
+Refer to scikit-bio's [API stability docs](http://scikit-bio.org/docs/latest/user/api_stability.html) for the current API lifecycle.
+
+- Prefer making new APIs experimental. This allows for changes to the API without needing to deprecate it first.
+- Try to avoid changing stable API if at all possible. If a change is necessary, deprecate the API and remove after 2+ minor releases.
+- Under extreme circumstances, a stable API can be changed without deprecation warning to users. This has happened in the past to fix bugs that required an API change. If this happens, discuss with other devs before committing to the change and document this change extensively in the changelog.
+- Always document stable/experimental API changes and any deprecated APIs in the changelog.
+
+## Integration/consistency with existing API
+
+When reviewing API changes/additions, look at them in the context of the rest of the codebase and its existing APIs. For example, are there existing parameter names that could be reused for consistency/predictability? Does the new API (or changed API) compose with other relevant APIs? Example: `skbio.stats.distance.anosim` uses a `permutations` parameter, so a new nonparametric function would want to use this name over something like `n` or `num_permutations`.
+
+## Commit messages and merging pull requests
+
+When merging pull requests, use GitHub's "Squash and merge" option to merge a single commit. See [this commit message](https://github.com/biocore/scikit-bio/commit/f3d736aabd717971332781b98d8fde861f354dc3) for an example.
+
+- Rewrite commit message to describe all changes being merged. This usually involves deleting individual commit messages that GitHub includes in the text box.
+- Include "fixes #n" text if there's an associated issue to be closed.
+- Use [numpy-style commit tags](https://docs.scipy.org/doc/numpy/dev/gitwash/development_workflow.html#writing-the-commit-message) (ENH, BUG, PERF, etc.).
+- Include contributors' and reviewers' GitHub usernames in commit message (attribution will be lost on squash).
+
+## Test changes locally
+
+**This step is extremely important.** Pull down the PR changes locally and try out the API as a user would. Try to break it, make sure the docs are complete, etc. Build the docs locally and verify that they render correctly (this is a common pitfall).
+
+## Docs
+
+- Verify the docs follow the instructions in the scikit-bio [documentation guide](https://github.com/biocore/scikit-bio/blob/master/doc/README.md).
+- Verify the docs follow [this page](http://scikit-bio.org/docs/latest/development/new_module.html) when adding a new module or subpackage to scikit-bio.
+- Public API should have docstrings conforming to [numpydoc standards](https://github.com/numpy/numpy/blob/master/doc/HOWTO_DOCUMENT.rst.txt). Manual and careful verification of the numpydoc docstrings is currently necessary; they are easy to get wrong and building the docs won't always flag issues. Building the docs and inspecting the rendered output can help with this process.
+- Package-private and private APIs do not need to be extensively documented; numpydoc docstrings are not required. Document these APIs as appropriate to help other devs understand the code (code comments are usually better for this anyways).
+
+## CI
+
+- Make sure Travis-CI is passing before merging a pull request.
+- Make sure coverage doesn’t drop. Strive to have 100% coverage for new code being merged.
+
+## Unit testing
+
+- Make sure the tests are as complete as possible.
+- Check that border cases are tested (e.g. zeros, '', [], None, etc.).
+- Check that the base case is tested (`n`), along with the inductive step (`n + 1`).
+- Verify that tests cover more than one input data set.
+- Make each test case simple, ideally only testing a single thing (follow [Arrange Act Assert](http://wiki.c2.com/?ArrangeActAssert)).

ci/conda_requirements.txt

 pip
-numpy
+# See note in setup.py install_requires about numpy version pin.
+numpy<1.14.0
 scipy
 matplotlib
 pandas
@@ -10,3 +11,4 @@ pyflakes
 flake8
 python-dateutil
 decorator
+scikit-learn

ci/pip_requirements.txt

@@ -3,7 +3,7 @@ coveralls
 natsort
 lockfile
 CacheControl
-git+git://github.com/sphinx-doc/sphinx.git
+Sphinx
 sphinx-bootstrap-theme
-git+git://github.com/numpy/numpydoc.git@1a848331c2cf53d4fe356f4607799524bcc577ed
+numpydoc < 0.8.0
 check-manifest

debian/changelog

+python-skbio (0.5.2-1) UNRELEASED; urgency=medium
+
+  * New upstream version
+  * Point Vcs fields to salsa.debian.org
+  * Standards-Version: 4.1.4
+  * debhelper 11
+
+ -- Andreas Tille <tille@debian.org>  Thu, 26 Apr 2018 09:16:46 +0200
+
 python-skbio (0.5.1-4) unstable; urgency=medium
 
   * Fix PYTHONPATH (thanks for the hint to Andreas Stührk

debian/compat

-10
+11

debian/control

@@ -5,7 +5,7 @@ Uploaders: Tim Booth <tbooth@ceh.ac.uk>,
            Kevin Murray <kdmfoss@gmail.com>
 Section: python
 Priority: optional
-Build-Depends: debhelper (>= 10),
+Build-Depends: debhelper (>= 11~),
                dh-python,
                ipython3,
                python3-all-dev,
@@ -25,19 +25,19 @@ Build-Depends: debhelper (>= 10),
                python3-setuptools,
                python3-sphinx,
                python3-sphinx-bootstrap-theme,
-               libssw-dev,
-Standards-Version: 4.1.1
-Vcs-Browser: https://anonscm.debian.org/git/debian-med/python-skbio.git
-Vcs-Git: https://anonscm.debian.org/git/debian-med/python-skbio.git
+               libssw-dev
+Standards-Version: 4.1.4
+Vcs-Browser: https://salsa.debian.org/med-team/python-skbio
+Vcs-Git: https://salsa.debian.org/med-team/python-skbio.git
 Homepage: https://github.com/biocore/scikit-bio
 
 Package: python-skbio-doc
 Architecture: all
+Section: doc
 Depends: ${misc:Depends},
          ${sphinxdoc:Depends},
-         libjs-mathjax,
-Recommends:  python3-skbio (= ${binary:Version})
-Section: doc
+         libjs-mathjax
+Recommends: python3-skbio (= ${binary:Version})
 Description: Data structures, algorithms, educational resources for bioinformatics (docs)
  Scikit-bio is a Python package providing data structures, algorithms, and
  educational resources for bioinformatics.
@@ -48,7 +48,7 @@ Package: python3-skbio
 Architecture: any-amd64
 Depends: ${shlibs:Depends},
          ${misc:Depends},
-         ${python3:Depends},
+         ${python3:Depends}
 Suggests: python-skbio-doc (= ${binary:Version})
 Description: Python3 data structures, algorithms, educational resources for bioinformatic
  Scikit-bio is a Python package providing data structures, algorithms, and

debian/patches/series

 mathjax-path
 0002-use-libsww-as-library-not-embedded-src.patch
 0003-Cherry-pick-upstream-fix-for-numpy-transition.patch
-0004-MAINT-compat-with-new-pandas-and-numpydoc-fix-deprec.patch
 no_privacy_breach_logo.patch

doc/source/conf.py

@@ -70,20 +70,7 @@ class NewAuto(autosummary.Autosummary):
 autosummary.Autosummary = NewAuto
 
 import sphinx_bootstrap_theme
-
-# We currently rely on the latest version of numpydoc available on GitHub:
-#   git+git://github.com/numpy/numpydoc.git
-#
-# There isn't a way to specify this in setup.py as a dependency since this
-# feature is being removed from pip. We also can't check the version of
-# numpydoc installed because there isn't a numpydoc.__version__ defined.
-try:
-    import numpydoc
-except ImportError:
-    raise RuntimeError(
-        "numpydoc v0.6 or later required. Install it with:\n"
-        "  pip install git+git://github.com/numpy/numpydoc.git@1a848331c2cf53"
-        "d4fe356f4607799524bcc577ed")
+import numpydoc
 
 @property
 def _extras(self):
@@ -119,7 +106,7 @@ from skbio.util._decorator import classproperty
 # If your documentation needs a minimal Sphinx version, state it here.
 # Using `sphinx_version` doesn't work, likely because Sphinx is expecting a
 # version string of the form X.Y, not X.Y.Z.
-needs_sphinx = '1.2'
+needs_sphinx = '1.6'
 
 # Add any Sphinx extension module names here, as strings. They can be
 # extensions coming with Sphinx (named 'sphinx.ext.*') or your custom

setup.cfg

+[nosetests]
+verbosity=0
+with-doctest=1
+doctest-tests=1
+doctest-extension=pyx
+ignore-files=DONT_IGNORE_ANYTHING

setup.py

@@ -106,6 +106,7 @@ setup(name='scikit-bio',
       packages=find_packages(),
       ext_modules=extensions,
       include_dirs=[np.get_include()],
+      setup_requires=['nose >= 1.3.7'],
       install_requires=[
           'lockfile >= 0.10.2',  # req'd for our usage of CacheControl
           'CacheControl >= 0.11.5',
@@ -113,11 +114,18 @@ setup(name='scikit-bio',
           'IPython >= 3.2.0',
           'matplotlib >= 1.4.3',
           'natsort >= 4.0.3',
-          'numpy >= 1.9.2',
-          'pandas >= 0.18.0',
+          # numpy array repr changed in 1.14.0 to use less whitespace, which
+          # breaks the doctests. The doctests can't be updated to match the new
+          # arrray repr because we still support Python 3.4, which doesn't have
+          # a numpy 1.14.0 conda package on `defaults` or `conda-forge`
+          # channels.
+          'numpy >= 1.9.2, < 1.14.0',
+          'pandas >= 0.19.2',
           'scipy >= 0.15.1',
-          'nose >= 1.3.7'
+          'nose >= 1.3.7',
+          'scikit-learn >= 0.19.1'
       ],
+      test_suite='nose.collector',
       classifiers=classifiers,
       package_data={
           'skbio.diversity.alpha.tests': ['data/qiime-191-tt/*'],

skbio/__init__.py

@@ -26,7 +26,7 @@ __all__ = ['Sequence', 'DNA', 'RNA', 'Protein', 'GeneticCode',
            'TreeNode', 'nj', 'read', 'write', 'OrdinationResults']
 
 __credits__ = "https://github.com/biocore/scikit-bio/graphs/contributors"
-__version__ = "0.5.1"
+__version__ = "0.5.2"
 
 mottos = [
     # 03/15/2014

skbio/alignment/_indexing.py

@@ -180,7 +180,7 @@ class TabularMSALoc(_Indexing):
         self._assert_tuple_rules(indexable)
         if (self._has_fancy_index() and
                 type(indexable) is not tuple and
-                pd.core.common.is_list_like(indexable) and
+                pd.api.types.is_list_like(indexable) and
                 len(indexable) > 0):
             if not self.is_scalar(indexable[0], axis=0):
                 raise TypeError("A list is used with complete labels, try"