Is it possible to reinstate the cpython 3.6 build?

[3tilley]

@marcelotrevisani @mariusvniekerk is it possible to revert this commit 5f8b8fb1123965eec1704c0feaa3c6487fbef310 that removes the cpython 3.6 runs? I'm aware that Python 3.6 is EoL, but it does still exist, and Open Telemetry supports it as it's minimum version. The OTel API is about to be stabilised for metrics, but we're blocked on migration because of having to support a range of environments.

If you let me know what I need to do I'm happy to learn how, it looks like I would run conda smithy rather than git revert or copying and pasting an existing 3.7 build, right?

[mariusvniekerk]

Given that adds a large amount of complexity that would add to managing the 50-60 or so opentelemetry feedstocks, this is probably not going to happen.

I would strongly recommend you move to a supported python version (probably 3.8)

[3tilley]

Thanks for getting back to me @mariusvniekerk

I fully appreciate the mess of having to maintain all the different versions, but in this case I think opentelemetry-api is the only one that has Python specific builds, at least from my rudimentary test: conda search "opentelemetry*" | grep py3. All of the other packages are Python only and depend on this.

What's more, --info for all the other latest versions of the packages show them with a minimum requirement of Python 3.6, even though they wouldn't actually be installable at that version due to the absence of a working opentelemetry-api - and the versions are pinned in lockstep so it's not possible to use an older opentelemetry-api:

$ conda search "opentelemetry-*" --info | grep python | tail -n 10
  - python >=3.6
  - python >=3.6
  - python >=3.6
  - python >=3.6
  - python >=3.6
  - python >=3.6
  - python >=3.6
  - python >=3.6
  - python >=3.6
  - python >=3.6

So in short, I think it's only this package that needs its 3.6 build reinstated to unlock the rest of the ecosystem. That'll allow us to continue migrations (and enable consistent telemetry to help us with those migrations).

If we don't want to enable a Python 3.6 build, and I can understand why not, can we go through the OTel packages and update the minimum Python version dependency to make it clear that the conda versions of these packages have a different support profile to those on PyPI?

[3tilley]

Hi @mariusvniekerk, have you had any further thoughts on this?

I was looking at adding some telemetry to conda itself, but unfortunately that has a minimum version of 3.6 as well: https://github.com/conda/conda/blob/master/setup.py#L64

[mariusvniekerk]

If you want telemetry for conda that would have to live in AnacondaRecipes and get built by Anaconda and published onto defaults. That is a different matrix than the one that conda-forge builds for.

Miniconda is only published for python>=3.7 atm

[3tilley]

Ok, I think I understand. So is the proposal that Anaconda would either clone this OTel recipe or create their own and host it on their channels to publish a 3.6 version?

Should I go through the opentelemetry-* recipes here in conda forge and open PRs to update their minimum version to 3.7?

[mariusvniekerk]

Newer releases of conda likely will require python >=3.7. Buf deferring to @jezdez on that