Merge pull request #1562 from croth1/modernize_docs

Author: beckermr

.ci_scripts/environment.yml

@@ -4,13 +4,12 @@ channels:
 dependencies:
   - python=3
   - conda-smithy
-  - sphinx<3
-  - docutils<0.18
+  - sphinx
   - cloud_sptheme
   - sphinxcontrib-fulltoc
   - make
   - xonsh
-  - recommonmark
+  - myst-parser
   - pyyaml
   - jinja2
   - requests

.ci_scripts/update_docs

@@ -26,7 +26,10 @@ rm -rf docs/
 python .ci_scripts/generate_cfep_index.py
 
 pushd src
-make html
+
+# -W --keep-going: list all warnings but fail build in case there are any
+# -n: check validity of all links
+make html SPHINXOPTS="-W --keep-going -n"
 mv _build/html ../docs
 rm -rf _build
 popd

misc/DEV_MEETING_TEMPLATE.md

@@ -1,6 +1,5 @@
 # YYYY-MM-DD conda-forge core meeting 
 
-****
 ## Attendees
 List the attendees for the meeting
 

src/conf.py

@@ -17,7 +17,6 @@
 import datetime
 
 import cloud_sptheme as csp
-import recommonmark.parser
 
 # If extensions (or modules to document with autodoc) are in another directory,
 # add these directories to sys.path here. If the directory is relative to the
@@ -33,6 +32,7 @@
 # extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
 # ones.
 extensions = [
+    'myst_parser',
     'sphinx.ext.todo',
     'sphinxcontrib.fulltoc',
     'sphinxcontrib.newsfeed',
@@ -41,10 +41,6 @@
 # Add any paths that contain templates here, relative to this directory.
 templates_path = ['_templates']
 
-# Transpile markdown into rest
-source_parsers = {
-    '.md': 'recommonmark.parser.CommonMarkParser',
-}
 
 # The suffix(es) of source filenames.
 # You can specify multiple suffix as a list of string:
@@ -86,7 +82,7 @@
 # List of patterns, relative to source directory, that match files and
 # directories to ignore when looking for source files.
 # This patterns also effect to html_static_path and html_extra_path
-exclude_patterns = ['_build', 'Thumbs.db', '.DS_Store']
+exclude_patterns = ['_build', 'Thumbs.db', '.DS_Store', 'README.md']
 
 # The reST default role (used for this markup: `text`) to use for all
 # documents.

src/maintainer/adding_pkgs.rst

@@ -754,10 +754,9 @@ Jinja expressions serve following purposes in the meta.yaml:
 
 - They allow defining variables to avoid code duplication. Using a variable for the ``version`` allows changing the version only once with every update.
 
-  .. code-block:: yaml
+  .. code-block:: yaml+jinja
 
       {% set version = "3.7.3" %}
-       [...]
 
       package:
         name: python
@@ -769,7 +768,7 @@ Jinja expressions serve following purposes in the meta.yaml:
 
 - They can call `conda-build functions <https://docs.conda.io/projects/conda-build/en/latest/resources/define-metadata.html#conda-build-specific-jinja2-functions>`__ for automatic code generation. Examples are the compilers, cdt packages or the ``pin_compatible`` function.
 
-  .. code-block:: yaml
+  .. code-block:: yaml+jinja
 
     requirements:
       build:

src/maintainer/pinning_deps.rst

@@ -106,7 +106,7 @@ be added by hand. To do this, follow these steps:
 
 #. Create a new migration yaml by copying `example.exyaml <https://github.com/conda-forge/conda-forge-pinning-feedstock/blob/master/recipe/migrations/example.exyaml>`__ in the ``conda-forge/conda-forge-pinning`` repository.
 #. Change the migration yaml to reflect the package and version to be migrated
-#. Write a :ref:`migrator <pin_migrator>` for propagating the pin changes.
+#. Write a migrator for propagating the pin changes.
 #. Propose the changes as a :term:`PR` to `conda-forge/conda-forge-pinning-feedstock`_.
 #. Once accepted the migration will begin. The migration status can be monitored at https://conda-forge.org/status.
 #. After the migration is complete, a new PR can be issued to `conda-forge/conda-forge-pinning-feedstock`_ to:

src/orga/minutes/2016-04-22.md

@@ -8,7 +8,7 @@ Subject: **How do we want to express recipes for particular VS versions.**
 
 *   New conda-build release - may be necessary for VS builds: [](https://github.com/conda/conda-build/releases/tag/1.20.1)[https://github.com/conda/conda-build/releases/tag/1.20.1](https://github.com/conda/conda-build/releases/tag/1.20.1)
 
-        *   Rebuild Eigen to test that the latest version works - if so we can drop [John Kirkham](https://conda-forge.hackpad.com/ep/profile/wv6uvIZX6h0)'s conda-smithy branch that tries to fix appveyor.
+        *   Rebuild Eigen to test that the latest version works - if so we can drop [John Kirkham](https://conda-forge.hackpad.comhttps://conda-forge.hackpad.com/ep/profile/wv6uvIZX6h0)'s conda-smithy branch that tries to fix appveyor.
     *   This has all been done and works now. In some cases Python 3.4 64-bit  builds on Windows have issues. That is still not understood.
 
 *   Current guidance at [](https://github.com/conda-forge/staged-recipes/wiki/VC-features)[https://github.com/conda-forge/staged-recipes/wiki/VC-features](https://github.com/conda-forge/staged-recipes/wiki/VC-features) and [](https://github.com/conda/conda/wiki/VC-features)[https://github.com/conda/conda/wiki/VC-features](https://github.com/conda/conda/wiki/VC-features). 

src/orga/minutes/2016-04-29.md

@@ -12,7 +12,7 @@ Agenda:
 
                 *   Question about conda-smithy/conda-build-all requirements. Please see reference to "Question 4.5" in [this comment](https://github.com/conda/conda-build/pull/848#issuecomment-215523101) 
 
-        *   Internal pinning mechanism. [Phil Elson](/ep/profile/AviM60TiesB) wrote some nice scripts here and they are very helpful.
+        *   Internal pinning mechanism. [Phil Elson](https://conda-forge.hackpad.com/ep/profile/AviM60TiesB) wrote some nice scripts here and they are very helpful.
     *   Questions:
 
                 *   How can we figure out what things need pinning?
@@ -52,7 +52,7 @@ Notes:
 *   Let's give webex a shot
 *   Dependency tracking
 
-        *   Currently baking in versions into the recipe, automated with script from [Phil Elson](/ep/profile/AviM60TiesB)
+        *   Currently baking in versions into the recipe, automated with script from [Phil Elson](https://conda-forge.hackpad.com/ep/profile/AviM60TiesB)
     *   Version choices are decided manually at the moment
     *   [](https://github.com/conda-forge/staged-recipes/wiki/Pinned-dependencies)https://github.com/conda-forge/staged-recipes/wiki/Pinned-dependencies
     *   What if we want to change a pinned version, say zlib 1.2 to 1.3?
@@ -92,7 +92,7 @@ Notes:
         *   Helpful when resolving problems, detecting when system Python
         *   Put it in, not too hard and will help downstream organizations
 
-All of the contents below were discussed between [Phil Elson](/ep/profile/AviM60TiesB) and [John Kirkham](/ep/profile/wv6uvIZX6h0). Many of the items have already been planned before and just need the details ironed out. Anything that required large group discussion was not decided in anyway.
+All of the contents below were discussed between [Phil Elson](https://conda-forge.hackpad.com/ep/profile/AviM60TiesB) and [John Kirkham](https://conda-forge.hackpad.com/ep/profile/wv6uvIZX6h0). Many of the items have already been planned before and just need the details ironed out. Anything that required large group discussion was not decided in anyway.
 
 *   Yum requirements
 
@@ -107,13 +107,13 @@ All of the contents below were discussed between [Phil Elson](/ep/profile/AviM60
 *   Adding a devtoolset to the container (for now).
 
         *   This was already merged (adds devtoolset-2).
-    *   [Phil](/ep/profile/AviM60TiesB) has rebuilt this.
-    *   [John](/ep/profile/wv6uvIZX6h0) tested the image with a trivial C++11 [program](https://github.com/jakirkham/hello_tests/blob/5b2f6b0c5682ecd84bee3be9cb73d790265f6002/hello.cxx) and that worked fine.
+    *   [Phil](https://conda-forge.hackpad.com/ep/profile/AviM60TiesB) has rebuilt this.
+    *   [John](https://conda-forge.hackpad.com/ep/profile/wv6uvIZX6h0) tested the image with a trivial C++11 [program](https://github.com/jakirkham/hello_tests/blob/5b2f6b0c5682ecd84bee3be9cb73d790265f6002/hello.cxx) and that worked fine.
     *   Automatic builds are not working. Will likely contact Docker to fix. However, this only matters if this problem still happens after moving the images.
 
 *   Movement of Docker images to common spaces (Docker Hub org, GitHub org).
 
-        *   [John](/ep/profile/wv6uvIZX6h0) will add the PRs to move Obvious-CI's Docker image to the org and from Obvious-CI.
+        *   [John](https://conda-forge.hackpad.com/ep/profile/wv6uvIZX6h0) will add the PRs to move Obvious-CI's Docker image to the org and from Obvious-CI.
     *   Docker Hub org is already setup
     *   Repo on GitHub is ready to go.
     *   Need to setup autobuilds for the image(s).

src/orga/minutes/2016-05-13.md

@@ -8,7 +8,7 @@ Hangout link: [](https://hangouts.google.com/call/v5olhwzpfzgzpoq5i3wthjpqpie)[h
 
 *   Jonathan Helmus
 *   Michael Sarahan
-*   [John Kirkham](/ep/profile/wv6uvIZX6h0)
+*   [John Kirkham](https://conda-forge.hackpad.com/ep/profile/wv6uvIZX6h0)
 *   Phil Elson
 *   Eric Dill
 *   Anthony Scopatz

src/orga/minutes/2016-06-03.md

@@ -6,7 +6,7 @@ Hangout link: [](https://hangouts.google.com/call/v5olhwzpfzgzpoq5i3wthjpqpie) [
 
 **Attendees**
 
-Ray, Matt, Jonathan, Phil, Jonas, Michael, Philippe, John, [Bjorn Gruning](https://conda-forge.hackpad.com/ep/profile/DMmBLyb21HK), Jan
+Ray, Matt, Jonathan, Phil, Jonas, Michael, Philippe, John, [Bjorn Gruning](https://conda-forge.hackpad.comhttps://conda-forge.hackpad.com/ep/profile/DMmBLyb21HK), Jan
 
 **Standing items**
 
@@ -52,7 +52,7 @@ Ray, Matt, Jonathan, Phil, Jonas, Michael, Philippe, John, [Bjorn Gruning](https
 
 *   Another   thing to consider here might be a new piece of metadata. For instance,   we could specify the primary language of a package. We could then   specify to `conda install`    that we want this language of a package. Possible syntax might include   something that looks like that of the above. Not sure how we want to   handled conflicts if we want to error, warn and install everything, or   something else.
 
-*   A simpler idea that we might consider that includes some of the ideas [Michael](https://conda-forge.hackpad.com/ep/profile/yHQTJXZ4gyS) mentioned above, but could be implemented without changes to `conda` or package metadata would be to place packages in labeled channels. That way all Python packages would be in `conda-forge/label/python`. This way one could simply add this labeled channel and get all the `python`  packages one wants. It's still a little fragile when enabling multiple  labels, but maybe this can leverage the channel resolution stuff that  Michael Grant has worked on.
+*   A simpler idea that we might consider that includes some of the ideas [Michael](https://conda-forge.hackpad.comhttps://conda-forge.hackpad.com/ep/profile/yHQTJXZ4gyS) mentioned above, but could be implemented without changes to `conda` or package metadata would be to place packages in labeled channels. That way all Python packages would be in `conda-forge/label/python`. This way one could simply add this labeled channel and get all the `python`  packages one wants. It's still a little fragile when enabling multiple  labels, but maybe this can leverage the channel resolution stuff that  Michael Grant has worked on.
 
 *   PR reviews