Dvc: Drop python 3.5 support?

[skshetry]

Advantages of Python 3.6+ codebase:

1. f-strings (on exceptions mostly, but yay!)
2. insertion-ordered dict (in 3.6, it's an implementation detail, but who's gonna change that?)
3. Supports Pathlike objects which will help us get rid of some helpers.
4. Typings, which we are planning to start using. (with support for variable annotations)
5. We will be supporting 3 versions (right now, it's 4)
6. Per download stats, 3.8 has overtaken 3.5 and number is quite low.

Regarding 5, Numpy and most of the data-science tools follow NEP29, by which they are on course to drop Python3.6 next month. Conda has already dropped support for Python3.5.

And, with the release of python 3.9, there will be a new version every year (with 5 years of support). Do we need to support all actively supported Python versions?

/cc @iterative/engineering

[casperdcl]

Based on PyPI, percentage-wise and in absolute terms, mac+win users are about as prevalent as py3.5 so don't think we should drop support yet. Still peaks around ~40 downloads/day just on PyPI alone.

Who needs users when you have developers?

Not a fan. I still support py2.6.

APIs are forever

P.S. in general for other packages it still looks like py3.5 > py3.8

[skshetry]

@casperdcl, Mac and Windows users don't have a choice (as they cannot just jump ship). Python3.5 users have enough choices (and, again, we build a tool, not a library).

And, providing Mac/Windows support is mostly strategic (to attract users) and make dvc an attractive tool.

[casperdcl]

Mac and Windows users don't have a choice (as they cannot just jump ship). Python3.5 users has enough choices

Don't agree at all. Everyone has a choice to put in lots of effort to change. Everyone tends to prefer not to. I have no doubt py3.5 users have equally valid reasons.

And, providing Mac/Windows support is mostly strategic (to attract users) and make dvc an attractive tool.

As is the point of legacy version support (advertising to py3.8 users that they will also be supported for years to come).

[casperdcl]

Not saying we shouldn't drop 3.5 support; I'm saying it seems premature.

[shcheklein]

@skshetry

and, again, we build a tool, not a library

this is not exactly true - people use it as a library, and let's not forget about dvc.api.

And, providing Mac/Windows support is mostly strategic (to attract users) and make dvc an attractive tool.

it it strategic, but not as pure marketing I would say. Windows is still popular in enterprises, for example, and we need to keep our expertise up to date there. Mac - I believe we have quite a lot users.

[efiop]

I agree with @skshetry , it makes a lot of sense to drop 3.5 support right now, as it will make developing new features much easier and will bump up the quality of the code with all the new features 3.6+ has. We run into 3.5 issues in pretty much every PR and have to waste our cycles on debugging it. There are over 4 times more 2.7 downloads then there are 3.5 downloads. 3.5 is not even a default python in ubuntu or fedora, they both have 3.6. Since 2.7 is dropped already, it doesn't make much sense to support 3.5 and waste our time on it.

[jorgeorpinel]

We will be supporting 3 versions (right now, it's 4)

What does this mean? That the tests on CI run on all these versions? But really the code base only needs to work for the oldest one (3.5 now?) since the following ones are backward compatible, correct? If so, it doesn't sound like a hard thing to do (supporting several versions) but Idk, haven't done any contributions to core in months 🙁

That said if the core team wants to migrate to 3.6 for it's features, it becomes a more attractive argument.

[skshetry]

it it strategic, but not as pure marketing I would say. Windows is still popular in enterprises, for example, and we need to keep our expertise up to date there. Mac - I believe we have quite a lot users.

@shcheklein, I meant the same with the word choice. I'm not saying it's just a marketing.

But really the code base only needs to work for the oldest one (3.5 now?)

Yes, you have to work with old python version whose EOL is just 3-4 months away. And, you have
to keep this in mind when developing a new feature.

@jorgeorpinel, let's say, we have our official release of 1.0 in June. That will leave 3 months of window for it's EOL. Either we wait for 3 months or just drop it now for 1.0.

That said if the core team wants to migrate to 3.6 for it's features, it becomes a more attractive argument.

There's 4 other points just above that.

[efiop]

Ok, guys. So so far looks like the team is for dropping it and there are no strong points against it. So we will be dropping 3.5 in the near future. Final 1.0 release will not support 3.5.

Side note: as noted by @shcheklein it would be nice to write down our python support policy somewhere in the docs, but that might be too early to do. So we'll keep that in mind for later. https://github.com/iterative/dvc.org/issues/1278