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

Remove support for Python 2.7 & 3.5 #1120

Closed
cyberw opened this issue Oct 23, 2019 · 9 comments
Closed

Remove support for Python 2.7 & 3.5 #1120

cyberw opened this issue Oct 23, 2019 · 9 comments

Comments

@cyberw
Copy link
Collaborator

cyberw commented Oct 23, 2019

Python 2 is no longer maintained (or at least it wont be at the end of this year).

A significant effort is required for any new code to be made 2.7 compatible, and we cant use new awesome features in 3.6 (f-strings ftw! :)

@AldenPeterson raised this in chat a while back, and compatibility was an issue (again) in a recent PR (#1119).

Opening this so we can have a discussion (I'm particularly interested if someone has a big need for 2.7/3.5 support).

@heyman
Copy link
Member

heyman commented Oct 23, 2019

I'd imagine that there are some old code bases out there that's still on python 2.7. I think we should drop the support at some point, but I'd prefer to keep it around for awhile longer. Since the extra work to support both versions is already in place, and it's usually not that much extra job to support both when implementing new features.

(Maybe I'm biased since I have quite a few website codebases (not locust related) in Python 2, and I'm dreading the day when I'll have to spend weeks migrating them)

@cyberw
Copy link
Collaborator Author

cyberw commented Oct 24, 2019

When Alden and I talked about it, I think he argued (and I support that) that most people have a lot bigger choice in what python version they run on the load gen side than on the server side.

@heyman
Copy link
Member

heyman commented Oct 24, 2019

@cyberw Yeah, I think that's true in general. However, I do know of companies that have large old locust test codebases that would still take time to migrate. I'd say let's wait for now and revisit this after the 2.7 has actually reached end of life :).

@lucrib
Copy link

lucrib commented Oct 24, 2019

if someone else agree with me that pytest is likely more used than locust inside python ecosystem, then consider the links below in order to drop support for py2.7 and py3.5.

@mbeacom
Copy link
Member

mbeacom commented Oct 26, 2019

When I raised this question in Slack, I was taking into consideration a codebase owner's ability to pin on the latest version to provide 2.7 support.

If an external repo is dependent on a version of locust able to be executed from 2.7, it would be advisable for them to pin to a 0.12.x series and we increment the version to a 0.13 or 0.2 minor to indicate the significance of the upgrade. This would provide us with a great deal of benefits...

Additionally, I assume Locust is more so a stand alone CLI/service in support of other projects, rather than a library being directly used by other projects. With that in mind, wouldn't it be advisable to be running locust from a secondary environment that's not tightly coupled with the codebase being tested (whether division via containers or other forms of environment separation or segregation)?

Some additional references in favor of this change:

@cyberw
Copy link
Collaborator Author

cyberw commented Jan 3, 2020

Python 2.7 is officially (unofficially) retired!

I'd like to suggest moving to 1.0 and removing 2.7 & 3.5 support, while simultaneously switching to locust package name instead of locustio (#817).

We could release a special locustio package that always fails to install, with an error message telling the user what to do (use a pinned version if they want to stay on py2, switch to "locust" if on py3). We could name it 0.1337 or something :)

@cyberw
Copy link
Collaborator Author

cyberw commented Jan 28, 2020

Resolved in #1243

0.14 release will pretend to support py2 but give an error on installation (so that users wont get stuck on an old version without knowing what is going on). In the next release (probably 0.14.1) we will remove py2 support from the package.

We can throw away lots of py2 compatibility code now, but that is a later topic.

I decided to leave the package renaming & 1.0 release for later (one step at a time...)

@cyberw
Copy link
Collaborator Author

cyberw commented Feb 3, 2020

New release is up!

0.14.2 will give an error if installed on py2 (this was supposed to happen in 0.14.0, but post install steps dont work for wheels based packages, so I had to release a source-only package)

0.14.3 (and onwards) are pure py3 versions and will not be downloaded by pip2.

@heyman
Copy link
Member

heyman commented Feb 3, 2020

Great work!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants