Merge branch 'master' into azure

Author: Aaishpra

.github/PULL_REQUEST_TEMPLATE.md

@@ -7,6 +7,6 @@ to `.html` files will only be effective if applied to the respective `.rst`.
 
 PR Checklist:
 
-- [ ] make all edits to the docs in the `src` directory, not in `docs`
+- [ ] make all edits to the docs in the `src` directory, not in `docs` or in the html files
 - [ ] note any issues closed by this PR with [closing keywords](https://help.github.com/articles/closing-issues-using-keywords)
 - [ ] put any other relevant information below

README.md

@@ -8,22 +8,25 @@ This repository
 
 If you have questions or need help, please check out our documentation for a [list of ways to interact with us](https://conda-forge.org/docs/user/how_to_get_help.html).
 
-## Building the docs
-
-The docs are built on GitHub Actions and run the `.ci_scripts/update_docs` script.
-To build the docs locally, you should do the following:
-1.  Clone the repository into your local machine.
-2.  Go into the main folder. </br>
-    Run the following commands.  
-3. `conda env create -f ./.ci_scripts/environment.yml`
-4. `conda activate conda-forge-docs`
-5. `cd newsfeed && pip install --no-deps .`
-6. `cd ../src`
-7. `make html`
-
 ## Improving the docs
 
-We are constantly improving our documentation and are very grateful for feedback and contributions. If you would like to help, please be aware that the html documentation in the `docs` folder is automatically generated from the source files in the `src` folder. Therefore please always edit the files in `src` and never in `docs`.
+- You can help to improve the documentation! It is version-controlled in the [conda-forge.github.io repository on GitHub](https://github.com/conda-forge/conda-forge.github.io).   The source text is stored in the src/ subdirectory and is formatted using Python’s [reStructuredText system](https://docutils.sourceforge.io/rst.html).
+
+- The docs are built on GitHub Actions and run the `.ci_scripts/update_docs` script.
+  We are glad to know that you would like to contribute. To build the docs locally, follow the steps mentioned below:
+1.  [Fork](https://docs.github.com/en/github/getting-started-with-github/fork-a-repo) the [conda-forge.github.io](https://github.com/conda-forge/conda-forge.github.io)        repository to your own GitHub user account.
+2.  [Clone](https://docs.github.com/en/github/creating-cloning-and-archiving-repositories/cloning-a-repository) this fork onto your computer.
+3.  Go into the main folder. </br>
+    Run the following commands.  
+      *  `conda env create -f ./.ci_scripts/environment.yml`
+      *  `conda activate conda-forge-docs`
+      *  `cd newsfeed && pip install --no-deps .`
+      *  `cd ../src`
+      *  `make html`
+4.  Make and commit your changes.
+5.  Submit a [pull request](https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests) to the main repository proposing your changes.
+
+**Note: "All changes must be made in the `/src` folder and NOT in the `/docs` folder. Html files in the ./docs folder are auto generated "**
 
 ## conda-forge dev meetings
 

src/maintainer/adding_pkgs.rst

@@ -16,20 +16,20 @@ Getting Started
 
 There are multiple ways to get started:
 
-#. Look at `the example recipe <https://github.com/conda-forge/staged-recipes/tree/master/recipes/example>`_ in the staged-recipes repository and modify it as necessary.
-#. If it is an R package from `CRAN <https://cran.r-project.org/>`_, please
-   instead start by using the `conda-forge helper script for R recipes <https://github.com/bgruening/conda_r_skeleton_helper>`_.
-   Then if necessary you can make manual edits to the recipe.
+#. Look at `the example recipe <https://github.com/conda-forge/staged-recipes/tree/master/recipes/example>`_ in the `staged-recipes repository <https://github.com/conda-forge/staged-recipes>`_ and modify it as necessary.
+#. If it is an R package from `CRAN <https://cran.r-project.org/>`_, kindly
+   start by using the `conda-forge helper script for R recipes <https://github.com/bgruening/conda_r_skeleton_helper>`_ instead.
+   Then if necessary, you can make manual edits to the recipe.
 #. If it is a python package, you can generate the recipe as a starting point with
-   ``grayskull pypi your_package_name``. To install it you can use `conda install -c conda-forge grayskull`. You do *not* have to use grayskull, and the
-   recipes produced by grayskull will need to be reviewed and edited.
+   ``grayskull pypi your_package_name``. To install it you can use ``conda install -c conda-forge grayskull``. You do *not* have to use ``grayskull``, and the
+   recipes produced by ``grayskull`` will need to be reviewed and edited.
    In particular, you'll at least need to check the build line to :ref:`use pip <use-pip>`,
    add yourself as a maintainer,
    and specify a ``license_file``.
 
 Your final recipe should have no comments (unless they're actually relevant to the recipe, and not generic instruction comments), and follow the order in the example.
 
-*If there are details you are not sure about please open a pull request. The conda-forge team will be happy to answer your questions.*
+*If there are any details you are not sure about please open a pull request. The conda-forge team will be happy to answer your questions.*
 
 In case you are building your first recipe using conda-forge, a step-by-step instruction and checklist that might help you with a successful build is provided in the following.
 
@@ -82,11 +82,11 @@ Checklist
 Feedback and revision
 ---------------------
 
-Once you finished your PR, all you have to do is waiting for feedback from our reviewer team.
+Once you finished your PR, all you have to do is wait for feedback from our review team.
 
-The reviewer team will assist you by pointing out improvements and answering questions. Once the package is ready, the reviewers will approve and merge your pull request.
+The review team will assist you by pointing out improvements and answering questions. Once the package is ready, the reviewers will approve and merge your pull request.
 
-After merging the :term:`PR`, our infrastructure will build the package and make it available in the conda-channel.
+After merging the :term:`PR`, our :term:`CI` infrastructure will build the package and make it available in the conda-channel.
 
 .. note::
 
@@ -157,7 +157,7 @@ staged-recipes directory.
 
      git checkout master
 
-#. Define the conda-forge/staged-recipes repository as “upstream” (if you have not already done so).::
+#. Define the conda-forge/staged-recipes repository as ``upstream`` (if you have not already done so).::
 
      git remote add upstream https://github.com/conda-forge/staged-recipes.git
 
@@ -231,7 +231,7 @@ You may need the openssl package, available on conda-forge
 Downloading extra sources and data files
 ........................................
 
-``conda-build 3`` supports multiple sources per recipe. Examples are available `in the conda-build docs <https://conda.io/projects/conda-build/en/latest/source/define-metadata.html#source-from-multiple-sources>`_.
+``conda-build 3`` supports multiple sources per recipe. Examples are available `in the conda-build docs <https://docs.conda.io/projects/conda-build/en/latest/resources/define-metadata.html#source-from-multiple-sources>`_.
 
 
 Build
@@ -312,7 +312,7 @@ Build, host and run
 
 Conda-build distinguishes three different kinds of dependencies.
 In the following paragraphs, we give a very short overview what packages go where.
-For a detailed explanation please refer to the `conda-build documentation <https://docs.conda.io/projects/conda-build/en/latest/source/resources/define-metadata.html#requirements-section>`__.
+For a detailed explanation please refer to the `conda-build documentation <https://docs.conda.io/projects/conda-build/en/latest/resources/define-metadata.html#requirements-section>`__.
 
 **Build**
 

src/maintainer/conda_forge_yml.rst

@@ -21,34 +21,35 @@ upload packages to anaconda.org, which can be useful for testing. For example:
 Top-level fields
 ================
 
-* appveyor
-* azure
-* self-hosted azure
-* build_platform
-* bot
-* channel_priority
-* channels
-* choco
-* circle
-* conda_forge_output_validation
-* docker
-* github
-* idle_timeout_minutes
-* linux
-* linux_aarch64
-* linux_ppc64le
-* os_version
-* osx
-* provider
-* recipe_dir
-* remote_ci_setup
-* skip_render
-* templates
-* test_on_native_only
-* travis
-* upload_on_branch
-* win
-
+* :ref:`appveyor`
+* :ref:`azure-config`
+* :ref:`self-hosted_azure-config`
+* :ref:`build_platform`
+* :ref:`bot`
+* :ref:`channel_priority`
+* :ref:`channels`
+* :ref:`choco`
+* :ref:`circle`
+* :ref:`conda_forge_output_validation`
+* :ref:`docker`
+* :ref:`github`
+* :ref:`idle_timeout_minutes`
+* :ref:`linux`
+* :ref:`linux_aarch64`
+* :ref:`linux_ppc64le`
+* :ref:`os_version`
+* :ref:`osx`
+* :ref:`provider`
+* :ref:`recipe_dir`
+* :ref:`remote_ci_setup`
+* :ref:`skip_render`
+* :ref:`templates`
+* :ref:`test_on_native_only`
+* :ref:`travis`
+* :ref:`upload_on_branch`
+* :ref:`win`
+
+.. _appveyor:
 
 appveyor
 --------
@@ -79,6 +80,8 @@ mapping for Azure-specific configuration options. For example:
       # built packages) as an Azure pipeline artifact that can be downloaded
       store_build_artifacts: False
 
+.. _self-hosted_azure-config:
+
 self-hosted azure
 -----------------
 Conda-Smithy is capable of doing things beyond CF's purposes, it also allows setting up
@@ -105,6 +108,8 @@ self-hosted agents for non-CF infrastructures. Here is an example demonstrating
 You can also use `Azure virtual machine scale set agents <https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/scale-set-agents?view=azure-devops>`_ 
 for autoscaling agents as they are cheaper to run than permanently active agents.
 
+.. _bot:
+
 bot
 ---
 This field controls the behavior of the ``auto-tick`` bot which issues
@@ -128,6 +133,8 @@ automatic version updates/migrations for feedstocks. The current options are
       abi_migration_branches:
         - v1.10.x
 
+.. _build_platform:
+
 build_platform
 --------------
 This is a mapping from the build platform to the host platform of the package
@@ -139,13 +146,17 @@ build platform using cross-compiling.
     build_platform:
       osx_64: linux_64
 
+.. _channel_priority:
+
 channel_priority
 ----------------
 
 This value sets the ``conda`` solver channel priority for feedstock builds. 
 The default is ``strict``. Any valid value for the same setting in the ``.condarc`` is
 allowed here.
 
+.. _channels:
+
 channels
 --------
 This represents the channels to grab packages from during builds and
@@ -165,6 +176,7 @@ has been built.  The ``channels`` variable is a mapping with
       targets:
         - ["conda-forge", "main"]
 
+.. _choco:
 
 choco
 -----
@@ -185,6 +197,8 @@ This is currently only implemented for Azure Pipelines. The command that is run
 ``choco install {entry} -fdv -y --debug``.  That is, ``choco install`` is executed
 with a standard set of additional flags that are useful on CI.
 
+.. _circle:
+
 circle
 --------
 The top-level ``circle`` key specifies configurations for the Circle
@@ -198,13 +212,17 @@ modified.  Tools like conda-smithy may modify this, as need.  It has a single
       secure:
         BINSTAR_TOKEN: <some big hash>
 
+.. _conda_forge_output_validation:
+
 conda_forge_output_validation
 -----------------------------
 
 This field must be set to ``True`` for feedstocks in the ``conda-forge`` GitHub
 organization. It enables the required feedstock artifact validation as described
 in :ref:`output_validation`.
 
+.. _docker:
+
 docker
 ------
 This is a mapping to docker configuration options. These are relatively
@@ -218,6 +236,8 @@ self-explanatory. The defaults are as follows:
       command: "bash"
       interactive: True
 
+.. _github:
+
 github
 ------
 This is mapping of configuration variables for GitHub. The
@@ -233,6 +253,7 @@ defaults are as follows:
       # branch name to execute on
       branch_name: master
 
+.. _idle_timeout_minutes:
 
 idle_timeout_minutes
 --------------------
@@ -243,6 +264,7 @@ don't have chatty enough builds. Currently only implemented in Travis and Circle
 
     idle_timeout_minutes: 60
 
+.. _linux:
 
 linux
 -----
@@ -254,6 +276,7 @@ Currently only:
     linux:
       enabled: False
 
+.. _linux_aarch64:
 
 linux_aarch64
 -------------
@@ -265,6 +288,7 @@ Currently only:
     linux_aarch64:
       enabled: False
 
+.. _linux_ppc64le:
 
 linux_ppc64le
 -------------
@@ -276,6 +300,8 @@ Currently only:
     linux_ppc64le:
       enabled: False
 
+.. _os_version:
+
 os_version
 ----------
 This key is used to set the OS versions for ``linux_*`` platforms. Valid entries map a linux platform and arch to either ``cos6``
@@ -286,6 +312,8 @@ or ``cos7``. Currently ``cos6`` is the default for ``linux-64``. All other linux
     os_version:
       linux_64: cos7
 
+.. _osx:
+
 osx
 ---
 The macOSX-specific configuration options. This is largely an internal setting.
@@ -296,6 +324,8 @@ Currently only:
     osx:
       enabled: False
 
+.. _provider:
+
 provider
 --------
 The ``provider`` field is a mapping from arch (operating system) to CI service.
@@ -346,6 +376,8 @@ To enable ``linux_ppc64le`` and ``linux_aarch64`` and the following:
       linux_ppc64le: default
       linux_aarch64: default
 
+.. _recipe_dir:
+
 recipe_dir
 ----------
 The relative path to the recipe directory. The default is:
@@ -354,6 +386,8 @@ The relative path to the recipe directory. The default is:
 
     recipe_dir: recipe
 
+.. _remote_ci_setup:
+
 remote_ci_setup
 ---------------
 This option can be used to override the default ``conda-forge-ci-setup`` package.
@@ -364,6 +398,8 @@ channel_alias if no prefix given.
 
     remote_ci_setup: "conda-forge-ci-setup=3"
 
+.. _skip_render:
+
 skip_render
 -----------
 This option specifies a list of files which conda smithy will skip rendering.
@@ -377,11 +413,15 @@ For example, if you want to customize .gitignore and LICENSE.txt file by your ow
       - .gitignore
       - LICENSE.txt
 
+.. _templates:
+
 templates
 ---------
 This is mostly an internal field for specifying where templates files live.
 You shouldn't need it.
 
+.. _test_on_native_only:
+
 test_on_native_only
 -------------------
 This is used for disabling testing for cross compiling. Default is ``false``
@@ -390,6 +430,8 @@ This is used for disabling testing for cross compiling. Default is ``false``
 
     test_on_native_only: True
 
+.. _travis:
+
 travis
 ------
 The top-level ``travis`` key specifies configurations for the Travis
@@ -403,6 +445,8 @@ modified.  Tools like conda-smithy may modify this, as need.  It has a single
       secure:
         BINSTAR_TOKEN: <some big hash>
 
+.. _upload_on_branch:
+
 upload_on_branch
 ----------------
 This parameter restricts uploading access on work from certain branches of the
@@ -415,6 +459,8 @@ master branch:
 
     upload_on_branch: master
 
+.. _win:
+
 win
 ---
 The Windows-specific configuration options. This is largely an internal setting.