Proposal: Drop support for Python 2 and Python < 3.6

[jjhelmus]

Python 2.7 has reached its end-of-life. Currently conda-build still supports installation into a Python 2.7 environment. In addition,the units tests are run against Python 2.7. I am proposing to drop support for installing conda-build into a Python 2.7 environment. It would still be possible to build Python 2.7 packages with future conda-build releases, but a Python 3 environment would be needed for installation.

At the same time it would be good to define the minimum Python 3 version. I am proposing that this minimum be Python 3.6 for the time being. Python 3.6 is proposed because:

• Python 3.5 reaches its end of life next month (2020-09-13).
• NEP 29 recommended dropping Python 3.5 support two months ago (2020-06-23) prior to January of 20202.
• Python 3.6 allow for the use of f-strings, a useful language feature.

The end result would be that future conda-build releases would require Python 3.6 or newer for installation. Again, building packages for older versions of Python, including 2.7, would still be supported. This change would only effect the environment where conda-build can be installed.

The benefits of dropping Python 2.7 and pre-3.6 version including the ability to simplify the source code using modern Python syntax a features. Additionally, the test matrix would be reduced allowing for quicker feedback from the CI on PRs.

What do others think?

[msarahan]

This is a great idea, and totally reasonable for a build tool. It's worth looking at how well conda-build behaves in a non-base env (I think reasonably well).

Other packages have done a major version bump for dropping py2.7. Probably a good idea here. Are there other breaking changes that would be good to make with a major version bump?

[jjhelmus]

This is a great idea, and totally reasonable for a build tool. It's worth looking at how well conda-build behaves in a non-base env (I think reasonably well).

My experience is that conda-build behaves well when installed into non-base environments provided you call it using conda-build .... conda build ... will try to use the version installed in the base environment.

Other packages have done a major version bump for dropping py2.7. Probably a good idea here. Are there other breaking changes that would be good to make with a major version bump?

Agreed, bumping the version to 4.0.0 is a good idea. I think there are a few un-used parameters in the conda_build.api function that could be removed with a major version bump. Making overlink checking on by default seems like another reasonable change.

[chenghlee]

Should we open a similar issue for conda as well?

[jjhelmus]

Should we open a similar issue for conda as well?

For sure!

[jakirkham]

This sounds great! 💯😄

[jjhelmus]

Given the favorable reaction to this proposal, I have created a 3.x branch for continued development of conda-build releases that support Python 2.7.

The master branch is now open to changes that do not support Python 2.7 or <3.6!

[Anthchirp]

NEP 29 recommended dropping Python 3.5 support two months ago (2020-06-23).

Just to point this out: NEP 29 recommended dropping Python 3.6 support two months ago (2020-06-23).

[jakirkham]

We had a similar discussion about Python 3.6 in the conda-forge meeting recently.

One of the issues that came up is PyPy has not released a version with Python 3.7 yet. So dropping Python 3.7 would mean losing PyPy support, which we (conda-forge) decided we didn't want to do.

FWIW we have clarified the conda-forge policy regarding which Python versions are supported in the docs.

This isn't to say that conda or conda-build should or shouldn't follow this. Merely another data point to be aware of when considering Python 3.6 support.

[jjhelmus]

Just to point this out: NEP 29 recommended dropping Python 3.6 support two months ago (2020-06-23).

Good catch, typo on my part I'll update the note with the date that was suggested for Python 3.5.

This proposal is the drop support for Python less than 3.6. Python 3.6 would still be supported. NEP 29 recommends dropping support for 3.6 in the PyData stack but I think it is worthwhile for conda-build to maintain compatibility for a bit longer.

[chrisjbillington]

My experience is that conda-build behaves well when installed into non-base environments provided you call it using conda-build .... conda build ... will try to use the version installed in the base environment.

conda-build in non-base environments is subject to this bug:

#3813

caused primarily by conda being a dependency, and thus getting installed into the non-base environment. I have wondered if conda-build should vendor the parts of the conda libraries it depends on, rather than conda being a dependency, that would resolve the issue. Either that or this bug in conda, that causes it to misbehave when installed in non-base environments, would need fixing:

conda/conda#9445

before conda-build would play nice with non-base environments.

[github-actions]

Hi there, thank you for your contribution!

This issue has been automatically marked as stale because it has not had recent activity. It will be closed automatically if no further activity occurs.

If you would like this issue to remain open please:

1. Verify that you can still reproduce the issue at hand
2. Comment that the issue is still reproducible and include:
   - What OS and version you reproduced the issue on
   - What steps you followed to reproduce the issue

NOTE: If this issue was closed prematurely, please leave a comment.

Thanks!