Consider requiring Python 3.6 at a minimum

[zenbot]

flit currently specifies that it requires python >=3, and has an actual requirement of python 3.4 at a minimum (because it imports pathlib, and doesn't install pathlib2). I would like to suggest that it bump that to python 3.6, because:

• there's so much good stuff in it
• it's widely available (e.g. CentOS/RHEL users have been able to yum install it straight from EPEL for months)

[takluyver]

One reason to be relatively cautious with the required version of Python here is that Flit will be automatically installed as a PEP 518 build tool to install packages from source. So there will be a tricky interaction between which Python versions your project supports and which Flit features it can make use of - you can only used things introduced when Flit still supported the oldest Python you require (assuming you care about source installs).

Not a deal breaker, but it means a) we probably have to be more conservative with version requirements than a straightforward developer tool, and b) we'll need to clearly document 'if you want to use these features, your minimum Python version is 3.5' (for example).

Of course, the biggest reason that I'm aware of this is people starting to have issues with Python 2.7, which Flit has never supported. I don't have a good answer for that.

[madsmtm]

I'll also just leave a reference to #244 and flit6, which tries to deal with the issue of supporting Python 2.7 in CI. I think it's okay that flit doesn't support Python 2.7, but it should keep compatiblity with all Python 3 versions as long as they haven't reached their EOL yet.

[zenbot]

@takluyver What is the minimum version of Python 3 that you'd like to support at this point?

[takluyver]

I'm not sure. Have you worked out what's the minimum version with which it currently works? We're testing back to 3.4 in Travis, but it may still work for older versions.

I certainly don't think we need to care about 3.2 or earlier. Beyond that, I'd probably keep supporting any version that currently works for as long as it seems practical.

[zenbot]

The minimum version with which flit works ATM is 3.4, due to its use of pathlib. (There may be other incompatibilities, that's just an obvious one!)

Tangentially — would you be open to the repo including tox config? It'd be nice to be able to run flit's tests against multiple interpreters outside of the context of GitHub's CI stuff.

[takluyver]

OK. Python 3.4 is still supported for a few more weeks, and still the default in Ubuntu 14.04 LTS, which is supported for a few more months. So, given the reasons to be conservative discussed above, let's keep 3.4 working for the time being, until there's some compelling reason to do otherwise.

I'm open in principle to Tox config, so long as it's not too ugly and doesn't need changing too often. I believe Tox was working on PEP 517 support, so this might be cleaner than it used to be. If it's working nicely enough, we could even use something like tox-travis to reduce duplication.

[takluyver]

See also #249 - if I follow the approach described there, we would have more conservative requirements for the core (maybe even going back to 2.7 :confused:), but we could more be more aggressive with requirements for the associated tooling (the command-line interface, validation, uploading, flit init, and so on).

[exhuma]

Please don't use 3.6 as a minimum just yet. I am currently tasked with reviewing the build & deploy workflow at work and we have a large server-farm running on LTS releases which still use 3.5.

After playing around with flit and pyproject.toml for the better part of the day I really begin to like it. Using 3.6 as a minimum would obviously be a deal breaker as we are still on 3.5.

We are reviewing moving to 3.7 that as our team really wants to have f-strings and data-classes. But we're not there yet. And it is currently not our priority.

And while I agree that 3.6 is so much nicer, I think a build tool like flit should err on the side of caution and aim to be conservative. Even our team is considering that our code will be migrated to 3.7, leveraging containers to be able to upgrade Python versions faster it could still mean that some of our builds rely on 3.5.

And I would really like to avoid having different workflows on different projects as much as possible.

[takluyver]

Don't worry, there's no near term plan to increase the minimum supported Python version, and I plan to be conservative with at least the essential core of it.