[codebase] Python 3.6 required

[jgsogo]

Python ecosystem is moving forward, Python 3.5 has reached EOL, and some core Conan dependencies will stop to support it, like requests >2.25.

Python 3.6 has also some valuable features that will help to improve the codebase and write more maintainable source:

• Formatted strig literals aka f-strings.
• Type hints for classes and instance variables.

---

• Upvote 👍 or downvote 👎 to show acceptance or not to the proposal (other reactions will be ignored)
  • Please, use 👀 to acknowledge you have read it, but it doesn't affect your workflow
• Comment and reviews to suggest changes to all (or part) of the proposal.

[foundry-markf]

Possibly worth considering 3.7 as the baseline, based on this tweet from Guido and the future annotations only being available in 3.7+ (https://www.python.org/dev/peps/pep-0563/)

Depends if type annotations is being considered. (I find them useful)

[madebr]

I just checked the what's new of python 3.7 and found the following features useful:

• Postponed evaluation of annotations: I don't know whether conan will add typing annotations (which would be very user friendly!!), but this would allow to do:

  class F:
      @classmethod
      def create_new(cls) -> F:
          return cls()

  instead of:

  class F:
      @classmethod
      def create_new(cls) -> "F":
          return cls()

• dataclasses are very useful to create data-only objects.
  collections.namedtuple can be used as well, but that does not transfer type information

These are very useful features which I personally like to use in my projects.
But for a global project such as conan, these can be worked around.

[jgsogo]

Sure, the latest the better, but in these proposals, we try to suggest what we consider to be the lowest we will feel comfortable with. If everyone is fine with a more modern version and it adds some valuable features, we will move to it.

I'm really surprised no one asking for support for older releases, btw. 🤔

[madebr]

I don't care that much about the minimum required versions of cmake and python as these are completely backwards compatible. (right?). These are almost always under control of devops, or are available as a portable zip.
The conan recipe is completely under our control and an API break between conan 1.0 and 2.0 is expected.
Older cmake scripts still work perfectly fine with newer (with extra warnings).

I'm more hesitant about requiring a minimum version of Visual Studio.
This feels the same as requiring gcc 8, Make 4.2, glibc 2.20, ...
Maybe some abstraction layer is required there? (I'll also comment in #5)

[puetzk]

No problem with 3.6, no objections to aiming higher yet. One thing I often struggle with, though, is how to ensure recipe code will be compatible with those running conan on older pythons. Maybe something like https://pypi.org/project/vermin/ or https://github.com/ghewgill/pyqver (no experience with either the former looks more robustly supported) could be integrated into the conan export linting?

[puetzk]

We've held at python 3.7 for now due to https://bugs.python.org/issue38989 causing bad interactions between pip and vcvars environments, but that's supposedly getting fixed in pip/distlib/packaging soon...

• 64 bit pip installs 32 bit DLLs (PyQt5 and PySide2) pypa/pip#8649
• tags.cpython_tags returns an incorrect value when run from a 32-bit VS developer prompt on a 64-bit Windows pypa/packaging#327
• Remove distutils.util usage from packaging.tags pypa/packaging#349

[jasal82]

f-strings are a real time-saver, especially when writing colored output so I support this suggestion ;) We have to use 3.8 anyway for some reason, I think it's because of a bug in the venv activation scripts on Windows in older versions.

[mathbunnyru]

I think, that if we want to discuss moving to a newer version of python as minimal (not 3.6, but 3.7 for example), a new PR has to be created because it's impossible to know, if a lot of people are fine with it.

[davidtazy]

I agree with this proposal

from https://www.jetbrains.com/lp/python-developers-survey-2019/

so python 3.6 will include > 90% of users. seems good
python 3.7 will exclude > 25% of users, not enough IMHO

[prince-chrismc]

I am curious about the thoughts on CentOS 7 support, which is LTS'd for another 4 years as I recall, many enterprises are burdened with still maintaining the platform in a bare/clean install.

[puetzk]

CentOS 7 is Python 2.7.5. I can't see conan retaining python 2.x as a target now (with all the major upstream packages dropping it), so you're going to have to install an an updated python from somewhere (e.g. https://github.com/iusrepo/python36)

But 3.7 is harder, since python now requires OpenSSL 1.1, (as I understand it) so you start needing to backport a lot more packages.

[prince-chrismc]

Yes but it's very easy to install 3.6, the oldest supported release is typically backported... yum install -y python3
Anything else would require a software collection

https://www.liquidweb.com/kb/how-to-install-python-3-on-centos-7/
https://developers.redhat.com/blog/2018/08/13/install-python3-rhel/

[rockdreamer]

I build >50 packages on Centos 7 using a combination of devtoolset-9 and python 3.6 from software collections. Here's a docker file that shows it's not that hard to do.
I wouldn't worry about it too much :)

[prince-chrismc]

I love your optimism, bring more of it please 😄

Sadly my industry has not gone containerization, let's not mention cloud... It's already a problem we have to deal with. it's a very uncomfortable thorn.
We build in a similar image (devtoolset7 however) but it still runs on a stock CentOS 7.
Many companies see changing tools as a waste of time and money since it does not generate sales or meet costumer demands. CentOS 7 enterprise users are there because they don't want to change, we gotten a massive push back from them even changing the development compiler, and that was a dev cut of the software not a major TLS.

We need to be contentious of c runtimes and ABI requirements, software still needs to be installed on a host machine (not just shipped in a container) for as much pain as it brings it also bring in sales.

[memsharded]

@mathbunnyru

I think, that if we want to discuss moving to a newer version of python as minimal (not 3.6, but 3.7 for example), a new PR has to be created because it's impossible to know, if a lot of people are fine with it.

Lets take this PR as a minimum proposal. If no one is requesting Python < 3.6. The biggest problem by far is letting some users down because they require older versions like 3.5 and for some reason cannot upgrade in some platforms. If we all agree that a 3.6 is a good minimum, we can try later to define a more modern one like 3.7. Also, other versions like CMake affect more at the user level, but the Python one will affect more maintainers. Users will be able to write their recipes in later versions, and we will run (as we do now already) Conan itself with latest Python to ensure that it is working fine.

[puetzk]

from https://www.jetbrains.com/lp/python-developers-survey-2019/

Good source, though it was published in May 2020 from data collected in Fall 2019, so it's about 12 months behind (about the release of 3.8.0). So the fraction of folks on 3.7 is probably better taken as "those who are roughly up-to-date" and 3.6 "those who are ~1 release behind", which would now be 3.9.0 and 3.8.0 (if folks have kept to those habits).

Though I'm rather confused that 3.9 is as high as 3%, given that it wasn't released until 5 October 2020, so that would (at the time) have meant basically meant either 3.9.0a1 or a recent build from master". Maybe Jetbrains kept updating the version chart after the rest of the survey closed (data from PyPI maybe)?

[ytimenkov]

Python 3.6 is a really safe minimal version because it's available even on RHEL 6 / CentOS 6 (which we still have to support).

As @puetzk Pointed out Python 3.7 requires newer OpenSSL version which means more work to get it working on those ancient distros.

However as a developer I appreciate that new versions are there and they solve problems and make writing code more pleasant (and indeed Python 3.7 has some useful features) so I won't complain if you chose to stick to 3.7 (or even higher) especially if it means fewer bugs and cleaner code :)

Also we wrap Conan into pyinstaller and deploy it as a standalone binary package so it doesn't depend much on what is really installed on the system so moving beyond python 3.6 just means compile few more things and given that Conan takes care of 90% issues I don't see this as a problem.

[jsteinhofff]

My 👎 is about todays situation. We still have Ubuntu 16.04 LTS in use (EOL in April 2021) which brings python 3.5 with it.
Aiming for somewhere after april 2021 i would totally aggree with python 3.6 (but more than that might again become a problem for us since i believe then again we will have Ubuntu 18.04 machines with python 3.6 around).
Of course you could also decide to accept that users might be forced to upgrade python on their system, but this again requires sudo-rights, costs time and overall might impact conan adoption.

[memsharded]

Aiming for somewhere after april 2021 i would totally aggree with python 3.6 (but more than that might again become a problem for us since i believe then again we will have Ubuntu 18.04 machines with python 3.6 around).

@jsteinhofff yes, that is totally the case, Conan 1.X will keep working with older versions, and Conan 2.0 will not happen earlier than that

[jsteinhofff]

Thanks @memsharded , i updated my vote :-)

[DoDoENT]

I am definitely in favour of Python 3.6 or newer, but I have a bit odd question: should we consider conan as a possible future proposal for standardization of C++ package management?

If yes, then any python could be problematic, as ISO standard may require definitions and specifications that could be implemented by others (e.g. build systems that may want to directly consume or create conan-compatible packages, without using the conan client).

In that case, I am a bit worried about using conanfile.py for recipes, as implementor of different clients will have to be able to interpret the Python code in public API methods, such as source, build, package_id, package, etc.

[memsharded]

I am definitely in favour of Python 3.6 or newer, but I have a bit odd question: should we consider conan as a possible future proposal for standardization of C++ package management?

The implementation of such a package manager will never be defined in such possible standard. I think the best we can hope is to have defined some interfaces, as the input and output format files for build systems that define what is a built package and what package you want to consume. Conan is very well prepared to adopt such possible standards. Plus moving away from conanfile.py recipes is undoable in any reasonable time frame, and would be massively breaking. We aim to a transition between Conan 1.X and Conan 2.0 with recipes that can work in both versions (not every currently existing recipe, but some updated versions)

[danimtb]

Thank everyone for the participation!

We have counted the votes and added the result as well as the number to the proposal document.

We consider the Python version 3.6 is appropriate as the minimum supported version for the next major version of Conan regarding the
features supported. Also, the votes reveal a clear consensus on upgrading the Python version without any major concerns in the discussion.

Thanks again for the feedback and we encourage you to participate in the upcoming proposals! 😄