[MacOS 12.3+] Chicken-egg problem: python vs Xcode CLI tools
Closed this issue · 4 comments
On a fresh macos VM install (12.4 in my case), https://github.com/samdoran/ansible-collection-macos/tree/main/roles/python suggests that Xcode CLI tools need to be installed before Python.
It looks like this wouldn't work for macos 12.3+ since it has /usr/bin/python
removed and /usr/bin/python3
is just a stub that needs Xcode CLI tools to operate.
The way these roles are written assumes presence of a Python interpreter on the target node. To activate it, one needs to install Xcode CLI tools but installing them through normal Ansible modules requires Python that is not there yet.
As part of going through the image building process in ansible-core-ci, I've faced this issue and my solution was to essentially rewrite https://github.com/samdoran/ansible-collection-macos/blob/main/roles/command_line_tools/tasks/main.yml using ansible.builtin.raw
. Having it in a pre-provisioning playbook allows to get the target Ansible-ready and proceed as usual.
So I guess I wonder if this collection would benefit from doing the same — either rewriting the roles not to rely on the pre-existing Python interpreter or providing an extra role specifically to cover this use-case.
I see what you mean. I'm wondering how the guest.yml
playbook worked in macOS < 12.3. Maybe /usr/bin/python
worked well enough to get things bootstrapped in < 12.3? I remember the python3
stub.
I looked through the instructions I wrote and it seems like guest.yml
is meant to be main entry point, so I assume it must have worked at the time I wrote it 🤷♂️.
Anyway, I think the best way forward is to rewrite the samdoran.macos.command_line_tools
to not rely on an installed Python version. Then the guest.yml
playbook in ansible-core-ci
can be changed to run samdoran.macos.command_line_tools
first.
Maybe
/usr/bin/python
worked well enough to get things bootstrapped in < 12.3?
Yes, python2 wasn't a stub up until it got deleted.
I looked through the instructions I wrote and it seems like
guest.yml
is meant to be main entry point, so I assume it must have worked at the time I wrote it 🤷♂️.
I believe it did.
Anyway, I think the best way forward is to rewrite the
samdoran.macos.command_line_tools
to not rely on an installed Python version. Then theguest.yml
playbook inansible-core-ci
can be changed to runsamdoran.macos.command_line_tools
first.
I was thinking that maybe this collection could even expose a playbook preparing the target to be Ansible-ready, given that a modern ansible-playbook
would be able to run that out of the box?
Take a look at #3 and let me know which approach you think is better.
Okay, I'll also post the playbook I've got there too.
Version 2.2.0 of the collection should address this issue.