To the few, the proud and the brave.
I have worked on and have a working(99%) Ansible + Python3 setup. I
am currently in the process of getting the PR into sane order. Testing
and validation have sucked up most of my time. Not a lot of pure
Python3 systems out there so value is still low. No impact on the
Python2x support at all save for some massive unicode hacks that will
have to be pared down into something sane.
that is all for today.
Hi.
Also, dammit 
There are various refactoring things we need to do over time which may prove such a patch extremely … non-timely, and I feel we need to get to many other PRs first, and this would also likely invalidate (and require update) of most PRs in queue.
I don’t want to say I’m disinterested in python 3 support for core – Luke Sneeringer has done some great work using “six” for the ansible-tower-CLI, though I think the answer here is a not now.
https://github.com/ansible/tower-cli
I don’t want to see a fork exist, that would be a disaster - and there will be a time for this, but that time will likely coincide with a point where python 3 is the default for more distros and it’s not easy to install python 2, and we need to update lots of modules.
So yeah, I don’t want to be that guy saying “hold off! We’re not ready to merge these things!” but yeah, I suspect we totally are not, and this would just complicate our workflow.
That time will come, and I am happy to see things like six available that should allow easy portability so we can run on both platforms (and in which case, yes, a tox.ini will be involved).
–Michael
A simple PR https://github.com/ansible/ansible/pull/8322
Text reads as"
"""
In an effort to understand Ansible code better I started to work on
adding Python3 support. Many projects like Apache's libcloud have
found the conversion to be much easier than they had feared. This pull
request only changes the print to be a function. Many stderr calls
were also addressed in a proper way and all tests pass fine. This is
me jumping into the development cycle to swallow yet another OSS
project process so point out my failures as they happen. I may have
softened at least one "wtf" found in print output, sorry about that.
"""
Ran 165 tests in 6.667s
OK
"""
"""
There will be a time for this later, but I’m afraid this is still jumping the gun and would complicate merging a lot of outstanding pull requests I think need to be addressed first.
Replied more formally to the ticket than I normally would have, since people tend to link to such things.
No worries. I guess I am missing what actually needs done on the PRs.
I can add more pull requests for other non-Python3 fixes but I do not
understand how I can reduce the number of pull requests currently.
Please advise in case I am missing some obvious action.
Lots of testing, review, mentoring, deciding if they are appropriate, fixing bugs that no one has fixed, implementing features that no one has fixed, answering questions, triaging issues, and lots of code review.
The time for python 3 can come later, but right now, I feel loyalty to dealing with all the other stuff first until the time comes.
There’s a bit of the “tragedy of github” in that it encourages code contribution and lots of extra work before asking if a project is wanting to go a certain way, so we do feel like we have to help out most of these PRs and try to negotiate reasonable compromises and implementations, and that takes a lot of time.
For this reason it’s almost always easier when someone has a feature proposal, if we discuss “what should we do for X” somewhat in advance, as otherwise we spend a lot of time trying to massage those things in.
Not so much a discussion of Python 3, but why the queue takes as much time as it does.
It’s been over 8 months since discussion about python 3, I think it’s time to start it once again. It shouldn’t be hard to keep code both 2-and-3 compatible (http://python-future.org/compatible_idioms.html). Python 3 is already 7 years old (https://www.python.org/download/releases/3.0/) it is widely, and can be easily installed on any distro not having it by default.
I’m not talking about abandoning python 2 support, but adding ability to run ansible with python 3. Well let’s say supporting python 2.6+ (sorry rhel 5.11 no new features for you) or 2.7+ (it may or may not work on rhel6).
If ansible resists to supporting python 3 and focues on 2.4 compability, it means that developers has to focus on archaic platforms that are no longer developed by anyone and receives only bugfixes.
BR,
Michal
Take a look at the v2 code (planned to be released as 2.0), Python3 compatibility is being worked on there.
Oh, great! But, shouldn’t v2 be kinda branch or something? Anyway, it’s great that work is already ongoing. If I wanted to contribute, where could I find resources, issues or whatever related to v2 project?
Oh, great! But, shouldn't v2 be kinda branch or something?
I have been wondering the same thing.
Anyway, it's great that work is already ongoing. If I wanted to
contribute, where could I find resources, issues or whatever related to v2
project?
v2 is a subdir in the repo; besides that afaik, there is no documentation
Yeah, not too much in the way of documentation yet -- you should be
able to checkout the git repo and the submodules as usual for hacking
on ansible from a git checkout. Then, instead of doing source
./hacking/env-setup do source ./v2/hacking/env-setup . That will set
the PATH and PYTHONPATH to use the code in the v2 subdirectory.
-Toshio
Hi,
Python 3 compatibility is something we want, but let me be clear, our
main user base is 2.4-2.7 by far, very few servers have python 3 by
default and we do not want to force an upgrade, but work with existing
infrastructure. As things change on the server side we will try to
keep the code 2-3 compatible as this is the trend we are seeing. At
some point, when python2 is less widely installed by default we'll
switch this portion of the code to be python3-only. We'll just have
to watch the ecosystems evolve to determine when to do this.
If you have ideas about how we can satisfy all consumers of modules we
will definitely listen.
So core ansible will probably make big strides to v3 compatibility but
task plugins/library modules will probably keep 2.4 compatibility for
a while. Our user base determines this, you would be surprised how
fast 2.4(modules) or even 2.6(core) incompatible code gets flagged by
them.
Please note that programmers will still be limited by v2
compatibility, so you will be able to execute under python 3 but not
add python 3 features to the code.
v2 will become devel after 1.9 is released so there should be no
changes in contribution methods.
Hi,
What do you think about “sorry, now new features for you, only bugfixes” attitude to 2.4-2.6 (or 2.4-2.5) versions, so potential developer won’t be limited by versions that it may be hard to get on modern distro?
Michal
That will happen when the majority of users have transitioned their
systems away from 2.4, as it stands now, not an option.
Ansible is a tool to serve the users, so they take priority over us
developers wanting to use features or syntax not readily available to
them.
I’m more of an user than developer, but I guess that you by user you mean business, user that pays for software, rather than hacker like me, and I’m okay with that. Anyway I’m happy that it’ll be possible to run ansible with py3.
I think this is more about supporting users that choose to use 'stable'
'enterprise' distributions, and are stuck with e.g. RHEL 5.x
Many users have no real choice in the matter. Bottom line, it should not be necessary to change your (supported) platform in order to use a config management / orchestration engine.
For hackers/developers, it's trivially simple to gain access to a python2.x environment to use. Its far more onerous to try and introduce a new python3 platform into an existing fleet of infrastructure, just to be able to keep up with new Ansible releases.
@Michal, no, by user i mean people using ansible, it does not matter
if they pay or not (ansible itself is free both as beer and as
speech).
Most people using a tool care more about how easy it is to install and
use than about the internal style or code features available, that
appeals to programmers that want to modify the tool (which is a small
subset of those using the tool).
Most of our users don't have an easy way to change other things they
run, we want to make ansible the easy choice and make it run w/o
causing them pain, much less forcing them to change their
infrastructure (hopefully we do make this easy once you start using
it!).
I’ve been stuck with rhel 5, I know their pain. I would say that “no new features” would be fair on platforms that are not going to get new features anyway, but discussion in this matter is going to be counterproductive. I’m not sure if and how I could contribute to v2 subdir-branch.
Follow instructions from here on how to get a git checkout:
http://docs.ansible.com/intro_installation.html#running-from-source
Where the instructions say to run source ./hacking/env-setup instead
do source ./v2/hacking/env-setup
That will setup up PATH and PYTHONPATH to use the code in ./v2/ansible .
-Toshio