search

samdoran / ansible-collection-macos

Ansible collection of roles and modules for use on macOS
8 stars 2 forks source link

[MacOS 12.3+] Chicken-egg problem: python vs Xcode CLI tools #1

Closed webknjaz closed 2 years ago

webknjaz commented 2 years ago

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.

samdoran commented 2 years ago

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.

samdoran commented 2 years ago

Take a look at #3 and let me know which approach you think is better.

webknjaz commented 2 years ago

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 :man_shrugging:.

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 the guest.yml playbook in ansible-core-ci can be changed to run samdoran.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.

samdoran commented 2 years ago

Version 2.2.0 of the collection should address this issue.