Build non-noarch package on older Python versions (3.6, 3.7, 3.8)

Package Builders conda-forge
1

I am trying to find a way to build a non-noarch package on older Python versions, but I cannot seem to find anything on it in the knowledge base. This is what I am trying to do -

build:
   skip: true  # [py<36]
   script: {{ PYTHON }} -m pip install . -vv --no-deps --no-build-isolation
   number: 3

but the CI keeps building the package (conda-forge/flt-feedstock#8) for Python 3.9+ -

image
image1532Ă—446 79.7 KB

Could someone let me know if it is indeed possible to build non-noarch packages on older Python versions? If it is, what exactly am I doing wrong?

Thank you!

2

All those python versions are end-of-life, in some cases already for many years. Conda-forge has stopped shipping updates for these versions, much less building packages for them. It’s strongly recommended that you and the users of your package move on to python 3.9+, because older python versions will run into more and more severe bitrot and incompatibilities w.r.t. globally pinned library versions, much less be exposed to unfixed CVEs.

That said, if you really want to aim a gun at your feet, you can add the following to recipe/conda_build_config.yaml and rerender:

python:
  # part of a zip_keys: python, python_impl, numpy, is_python_min
  - 3.6.* *_cpython
  - 3.7.* *_cpython
  - 3.8.* *_cpython
  - 3.9.* *_cpython
  - 3.10.* *_cpython
  - 3.11.* *_cpython
  - 3.12.* *_cpython
python_impl:
  - cpython
  - cpython
  - cpython
  - cpython
  - cpython
  - cpython
  - cpython
numpy:
  - 1.19
  - 1.21
  - 1.22
  - 1.22
  - 1.22
  - 1.23
  - 1.26
is_python_min:
  # non-sensical for your usecase, but best to not touch the defaults
  - false
  - false
  - false
  - true
  - false
  - false
  - false
3

Thank you for the detailed response! I am aware of the EOL of the Python versions listed by me above, but some of the packages I put on conda-forge are unmaintained on PyPI; hence, I do not want the 2 distributions’ metadata or Python version support to drift apart from each other.

I am hoping that is how it should be, and the minimum Python version update should be triggered the other way around (PyPI/GitHub metadata first, conda-forge metadata second).

1 Like