Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Drop python 3.5 support? #3765

Closed
skshetry opened this issue May 8, 2020 · 9 comments · Fixed by #3792
Closed

Drop python 3.5 support? #3765

skshetry opened this issue May 8, 2020 · 9 comments · Fixed by #3792
Assignees
Labels
discussion requires active participation to reach a conclusion question I have a question?

Comments

@skshetry
Copy link
Member

skshetry commented May 8, 2020

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?

New schedule of Python releases starting with 3.9 where new version is released annually

/cc @iterative/engineering

@skshetry skshetry added question I have a question? discussion requires active participation to reach a conclusion labels May 8, 2020
@casperdcl
Copy link
Contributor

casperdcl commented May 8, 2020

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
Copy link
Member Author

skshetry commented May 8, 2020

@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
Copy link
Contributor

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
Copy link
Contributor

casperdcl commented May 8, 2020

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

@shcheklein
Copy link
Member

@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
Copy link
Contributor

efiop commented May 8, 2020

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
Copy link
Contributor

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
Copy link
Member Author

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
Copy link
Contributor

efiop commented May 11, 2020

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. iterative/dvc.org#1278

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion requires active participation to reach a conclusion question I have a question?
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants