Skip to main content

conda-forge is moving to producing conda artifacts in the version 2 package format (also known as .conda). These artifacts allow for more efficient indexing and maintenance of the ecosystem. Our admin migrations bot will begin making PRs to feedstocks to change them over to the new artifact format. You will need conda version 4.7 or later to use the new .conda artifacts. Please leave a comment on this issue if you encounter problems or have feedback.

The CPython versions 3.8.14, 3.9.14, and 3.10.7 were released some weeks ago to mitigate CVE-2020-10735. The chosen mitigation strategy might cause errors (e.g. ValueError: Exceeds the limit (4300) for integer string conversion) in some libraries. If you are affected, please read the announcement and learn about the available workarounds in the CPython documentation.

The conda-forge team has decided to build and publish these releases with no additional changes. The new packages will be made available on or after 2022-11-10, following Anaconda's decision.

Conda is moving to CalVer per CEP 8. The first CalVer and last SemVer should be 22.9.0 and 4.14.0 respectively. This change maintains version order so you should not expect any issues.

Conda-Forge has been providing support for Python 3.7 for 4 years now.

Increasingly projects are moving off it (particularly in the PyData community). With Python 3.11's release coming around the corner (October 3rd), conda-forge plans to drop Python 3.7 support when Python 3.11 comes out. This will lighten the load on conda-forge infrastructure and make room for the new versions the community would like to support.

More details can be found in issue conda-forge-pinning-feedstock#2623. Feedback is welcome there.

Conda-forge has supported PyPy since almost 2.5 years now, and the initial PyPy 3.7 builds have been superseded in almost all aspects by the newer builds for 3.8 & 3.9. We are therefore dropping PyPy 3.7 as a supported python version, and will keep focusing on the more contemporary PyPy builds.

Microsoft has deprecated the Visual Studio (VS) 2017 compiler and removed it from all the CI they control (notably Azure Pipelines & Github Actions). This means that the default toolchain (== C/C++ compiler, linker, standard libraries, and related utilities) of that VS version - vc141 - is getting less and less use in upstream libraries (because public hosted CI doesn't use it anymore by default), and therefore support for it is bitrotting at an accelerating pace. We are therefore planning to move our toolchain on windows to vc142 (the default in VS2019) in two weeks, on 2022-08-25.

This will not affect you as a general user of conda-forge packages on windows; the only impact is that if you are locally compiling against artefacts produced by conda-forge and are still using VS2017 yourself, you will need to upgrade your compiler (VS2019 is a drop-in replacement & ABI-compatible).

Azure is removing their OSX 10.15 VM image and so we are bumping to 11. You will need to rerender your feedstock to get this change. Feedstocks without the new VM image specified will not build after Azure fully removes the old image. Please get in touch with us if you have issues or questions!

After more than six months, the conda-forge team and contributors have managed to update the Qt5 packages to the latest LTS version, 5.15.2. Major changes include separating the package for QtWebEngine (qt-webengine) from the rest of Qt (now in a new package called qt-main). This allows recipes that do not use any of the WebEngine components to depend only on qt-main, reducing the total size of the downloaded binaries. As a result of this, qt will be a metapackage that installs both qt-main and qt-webengine as dependencies. With respect to PyQt, the new packages now are in sync with respect to their corresponding PyPI releases, which means that the pyqt package will only provide the core components of Qt, leaving pyqtwebengine and pyqtcharts as optional packages that extend PyQt by providing the QtWebEngine and QtCharts components, respectively. A migrator will be put in place to help with the transition.

A GitHub action now monitors comments on issues in staged-recipes and will add language and review labels to issues/PRs when a staged-recipes sub-team is mentioned in a comment. It adds the Awaiting author contribution label if a member of staged-recipes removes the review-requested label. Unlike notifications, which are only sent to the users which are members of a team at the time of the mention, labels are persistent and visible to everyone, so they should be very helpful for identifying old PRs that need attention.