Merge pull request #1838 from conda-forge/python-patching

Author: beckermr

src/maintainer/knowledge_base.rst

@@ -700,7 +700,7 @@ MPI Compiler Packages
 
 Do not use the ``[openmpi,mpich]-[mpicc,mpicxx,mpifort]`` metapackages in the ``requirements/build`` section
 of a recipe; the MPI compiler wrappers are included in the main ``openmpi``/``mpich`` packages.
-As shown above, just add ``openmpi``/``mpich`` to the ``requirements/host`` section and use compiler directives for the 
+As shown above, just add ``openmpi``/``mpich`` to the ``requirements/host`` section and use compiler directives for the
 corresponding compilers in ``requirements/build`` as normal.
 
 
@@ -1568,7 +1568,7 @@ Once the PR is merged, the dependency graph is built. After that, the bot walks
 
 Usually, the bot generates these migrations automatically. However, when a pin is first made or added, one may need to be added by hand. To do this, you can follow the steps mentioned in `Updating package pins <https://conda-forge.org/docs/maintainer/pinning_deps.html#updating-package-pins>`__.
 
-The way migrations proceed are: 
+The way migrations proceed are:
 
   1. You make a PR into the ``migrations`` folder in the `conda-forge-pinning-feedstock <https://github.com/conda-forge/conda-forge-pinning-feedstock>`__ with a new yaml file representing the migration.
   2. Once the PR is merged, the bot picks it up, builds a migrator graph, and begins the migration process.
@@ -1586,13 +1586,25 @@ Another reason why it is good to keep the PR open or in draft status is that peo
 Security considerations for conda-forge builds
 ==============================================
 
-All ``conda-forge`` packages are built by strangers on the internet on public cloud infrastructure from source code you likely have not inspected, so you should not use ``conda-forge`` packages if you or your team require a high level of security. 
+All ``conda-forge`` packages are built by strangers on the internet on public cloud infrastructure from source code you likely have not inspected, so you should not use ``conda-forge`` packages if you or your team require a high level of security.
 You are also free to download recipes and rebuild them yourself, if you would like at least that much oversight. However, many people use ``conda-forge`` all the time with no issues and here are some things that ``conda-forge`` does to help with security in some ways:
 
 1. `Sources <https://conda-forge.org/docs/maintainer/adding_pkgs.html#source>`_ (where you specify where the package's source code is coming from) can be pulled from GitHub, PyPI, or other sources and sha256 hashes are always used, so moving of tags or uploading of new sdists can not cause automatic package rebuilds.
    Also, once packages are accepted and made into feedstocks, only the maintainers of that feedstock have the right to merge PRs made to that feedstock.
-2. Each feedstock can only upload packages for that feedstock. This is enforced by using a cf-staging channel where builds are first sent. 
+2. Each feedstock can only upload packages for that feedstock. This is enforced by using a cf-staging channel where builds are first sent.
    A bot then assesses that the submitting feedstock has permission to build the package it has submitted, and only then will it relay the build to the conda-forge channel.
    This helps mitigate against a bad actor gaining access to an inconspicuous feedstock and then trying to push a build with malicious code into essential infrastructure packages (e.g., OpenSSL or Python).
 3. We have `artifact-validation <https://github.com/conda-forge/artifact-validation>`__ for validating all the ``conda-forge`` artifacts before they are uploaded to ``anaconda.org``. This validation looks for various security-related items, such as artifacts that overwrite key pieces of certain packages.
 4. We have a dedicated `Security and Systems Sub-Team <https://conda-forge.org/docs/orga/subteams.html?highlight=security+team#security-and-systems-sub-team>`__ who works hard towards making sure to secure and maintain appropriate access to the credentials and services/systems used by ``conda-forge``.
+
+Significant Changes To Upstream Projects
+========================================
+
+From time to time, we make changes in upstream projects so that they better integrate into the ``conda-forge`` ecosystem. We
+have listed some, but not all, of those changes here for specific projects along with any associated documentation.
+
+Python
+------
+
+We carry an extensive set of python patches that change some core behaviors around search paths, environment isolation
+in conda environments, and some operating system limits. See the `python feedstock <https://github.com/conda-forge/python-feedstock>`_ for more details.

src/maintainer/maintainer_faq.rst

@@ -79,7 +79,7 @@ FAQ
 
   - ``conda install boa -c conda-forge``
   - ``conda mambabuild myrecipe``
-  
+
   For more details visit `this <https://boa-build.readthedocs.io/en/latest/mambabuild.html>`__ page.
 
 .. _mfaq_conda_verify:
@@ -181,3 +181,15 @@ FAQ
   .. note::
 
     Even if the maintainer isn't active anymore, we generally like to keep them in the list of maintainers and not remove them, in case they want to take up maintenance at a later date.
+
+.. _mfaq_changes_to_major_projects:
+
+:ref:`(Q) <mfaq_changes_to_major_projects>` **Does ``conda-forge`` ever make significant changes or apply code patches to significant upstream packages?**
+
+  We generally try to avoid changes, but there are many notable exceptions and we have no set policy. These changes currently fall into
+  a few categories. Upstream projects that violate our community norms or pose significant security risks through their policies may
+  be changed so that they can be distributed on ``conda-forge``. In many cases though, these projects are not distributed at all. We
+  do employ extensive changes to project build scripts in order to properly build and install projects into conda environments.
+  Finally, in some cases we add, enable, or disable features in specific projects to ensure they are broadly compatible with the
+  ``conda-forge`` package set. The set of patches/changes we apply is always located in the feedstock that built the package. We
+  also maintain a list of important packages with changes in our documentation.

src/user/faq.rst

@@ -65,12 +65,12 @@ FAQ
 
 :ref:`(Q) <faq_compiler_metapkg>` **How can I install a C/C++ compiler in my environment?**
 
-  You can use our convenient meta-packages ``c-compiler`` and ``cxx-compiler`` to install a compiler stack that fits your platform. Error messages such as 
-  
+  You can use our convenient meta-packages ``c-compiler`` and ``cxx-compiler`` to install a compiler stack that fits your platform. Error messages such as
+
   .. code-block::
 
     x86_64-apple-darwin13.4.0-clang: No such file or directory
-    
+
   are a telltale sign that you are lacking compilers.
 
 .. _faq_compiler_required_options:
@@ -98,7 +98,7 @@ FAQ
   build with some of the flags supplied by conda-forge?  What if you are building something that
   is setup for cross-compiling and expects ``CC`` to contain the name of the target toolchain but
   wants to be able to build some things for the build-host to use during the build by just calling
-  ``gcc``? 
+  ``gcc``?
 
   The :ref:`compiler metapackages mentioned above <faq_compiler_metapkg>` also install packages that
   create symlinks of the short names (like ``gcc``) to the actual toolchain binary names (like
@@ -128,14 +128,14 @@ FAQ
 :ref:`(Q) <faq_cuda_compiler_header>` **How can I compile CUDA (host or device) codes in my environment?**
 
   Unfortunately, this is not possible with conda-forge's current infrastructure (``nvcc``, ``cudatoolkit``, etc) if there is no local CUDA Toolkit installation. In particular, the ``nvcc`` package provided on conda-forge is a *wrapper package* that exposes the actual ``nvcc`` compiler to our CI infrastructure in a ``conda``-friendly way; it does not contain the full ``nvcc`` compiler toolchain. One of the reasons is that CUDA headers like ``cuda.h``, ``cuda_runtime.h``, etc, which are needed at compile time, are not redistributable according to NVIDIA's EULA. Likewise, the ``cudatoolkit`` package only contains CUDA runtime libraries and not the compiler toolchain.
-  
+
   If you need to compile CUDA code, even if it involves only CUDA host APIs, you will still need a valid CUDA Toolkit installed locally and use it. Please refer to `NVCC's documentation <https://docs.nvidia.com/cuda/cuda-compiler-driver-nvcc/index.html>`_ for the CUDA compiler usage and `CUDA Programming Guide <https://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html>`_ for general CUDA programming.
 
 .. _faq_abi_incompatibility:
 
 :ref:`(Q) <faq_abi_incompatibility>` **How to handle breaking of a package due to ABI incompatibility?**
 
-  If your package breaks ABI with a version bump, here are a few steps you can take to fix it: 
+  If your package breaks ABI with a version bump, here are a few steps you can take to fix it:
 
   - Rebuild the new version with corrected ``run_exports``.
   - Rebuild the old version with corrected ``run_exports``.