-
Notifications
You must be signed in to change notification settings - Fork 3k
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
Comments
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) |
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. |
@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 :). |
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. |
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 If an external repo is dependent on a version of 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: |
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 :) |
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...) |
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. |
Great work! |
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).
The text was updated successfully, but these errors were encountered: