Replies: 4 comments 2 replies
-
Almost everything in the Python ecosystem has moved to version 3 now, so you have a good basis for dropping support at this point. On top of that, ksconf occupies a spot in the 'build/deployment' lifecycle of code, which is often the easiest area to change versions, as opposed to running production code. |
Beta Was this translation helpful? Give feedback.
-
For me, you should drop support for Python 2.7. Keep a release available for those who have not switch yet. but i'm not sure if you'll need the branch or not :) |
Beta Was this translation helpful? Give feedback.
-
I would also suggest dropping py2 sooner than later. Agreed on the branch point for anybody stuck with it. |
Beta Was this translation helpful? Give feedback.
-
Ksconf 0.10.0 and later no longer supports Python 2. Dropping this discussion. |
Beta Was this translation helpful? Give feedback.
-
Quick question for the KSCONF users out there: How important is that we keep supporting Python 2.7? With newer versions being shipped with Splunk starting in 8.0, and 2.7 being rapidly dropped by upstream library maintainers, it would be helpful to get some feedback from the community to guide my thinking on the topic. I'd like jump straight to Python 3.6 being the minimum version, right now you can basically make it work on 3.4, in most cases. Will jumping straight to 3.6 be a challenge for anyone?
My current plan is to stop supporting Python 2.7 as soon as Splunk drops it (some future Splunk 9.x), but as I've switched my primary development to Python 3 first, I'm finding that the ongoing cost of compatibility, additional requirements for backport packages, and the like is getting costly in terms of my development efficiency. Therefore, I'm thinking about maybe dropping it sooner.
I'll probably make a
so-sorry-youre-still-stuck-on-py27
branch, for emergency bug fixes, but otherwise would like to get to a Python 3.6+ code base as quickly as possible.Beta Was this translation helpful? Give feedback.
All reactions