fix: simplify podman executable path lookup

[gardar]

Avoids unnecessary command tasks and removes which as a dependency that is not always present in minimal environments. (It's not available in https://github.com/ansible/creator-ee for example).

[apatard]

I don't know the playbook but I'm wondering why you're not changing things to use containers.podman collection ?

[gardar]

@apatard I'm not a maintainer and I'm just submitting fixes/improvements for issues that I'm running into while using the driver, but I've actually wondered about that myself, why this driver is using the shell/command modules instead of the podman modules.
I can't find any issues/discussions on the subject so I'm guessing that at the time the driver was made the podman modules didn't exist or were too limited.

I opened a issue on the subject where we can discuss this further. ansible-community/molecule-plugins#78

[ssbarnea]

I can answer this one. Podman collection was not really actively maintained and that gave more flexibility. Things change, I am not against using it, but be sure it is maintained.

[ssbarnea]

Use of lookup is not acceptable as it runs on control machine! Good that I remembered that before merging it.

[ssbarnea]

Basically the real fix for this bug is a single line change that replaces which with command -v, nothing else.

[gardar]

Use of lookup is not acceptable as it runs on control machine! Good that I remembered that before merging it.

But isn't this step of driver always running on the controller anyways?

[ssbarnea]

Use of lookup is not acceptable as it runs on control machine! Good that I remembered that before merging it.

But isn't this step of driver always running on the controller anyways?

Happens to be on controlled does not mean it will always be that. Think about users using remote container machines. I would prefer to use command -v which is safe and portable.

[gardar]

Use of lookup is not acceptable as it runs on control machine! Good that I remembered that before merging it.

But isn't this step of driver always running on the controller anyways?

Happens to be on controlled does not mean it will always be that. Think about users using remote container machines. I would prefer to use command -v which is safe and portable.

Ok I'm fine with command -v, it should be built into most common shells.

I didn't realize that molecule could execute drivers that are located on a different host than molecule itself. But since that's the case I assume we should get rid of all the other lookups too?

[ssbarnea]

Depends. Not all lookups are risky.

[zhan9san]

Think about users using remote container machines.

IMHO, the container client will still run on the controller, does't it?

[gardar]

Depends. Not all lookups are risky.

I didn't think that the first found lookup would be considered risky, I thought the issue with using a lookup would be because the lookup simply wouldn't work.

IMHO, the container client will still run on the controller, does't it?

That was what I thought and then the lookups would behave exactly like any other task, since it's being ran against localhost anyways.
But since that is not the case, I'm curious as to how you can do it remotely as I haven't come across any documentation hinting as to how you can execute the driver remotely.