/usr/bin/az wrapper does not account for environments where an alternate python is used (RHEL8)

[msftvito]

Describe the bug

The 'az' shell script wrapper that sets up the call to python created during the RPM build process (scripts/release/rpm/azure-cli.spec) uses the first python3.9 that it finds in PATH:

python_cmd=python3.9
if command -v python3.9 &>/dev/null; then python_cmd=python3.9; fi
AZ_INSTALLER=RPM PYTHONPATH="$bin_dir/../lib64/az/lib/python3.9/site-packages" $python_cmd -sm azure.cli "$@"

However, we often times run az within scripts in environments where we use our own non-system Python that may not be compatible with az that can cause azure-cli to fail. Since the dnf/yum install process properly pulls down the system python3.9 as a dependency, it makes sense that az should call that instead of relying on what's in the user's environment. I realize based on the various commits and history that this is a very finicky and multi-faceted issue since many OS/distributions are involved, but at least for us it makes sense to explicitly set the PATH or python to be used so that azure-cli can be used even in environments where a conflicting Python is required. As an example, dnf uses #!/usr/libexec/platform-python in RHEL like distros.

It is possible to work around this issue by wrapping around the az wrapper and setting the right values explicitly, but it makes more sense to have the actual az wrapper handle the logic correctly in the first place.

Related command

Steps to reproduce using a Rocky Linux 8 container:

docker run -it rockylinux:8 /bin/bash

#Install Azure-CLI
rpm --import https://packages.microsoft.com/keys/microsoft.asc
dnf install -y https://packages.microsoft.com/config/rhel/8/packages-microsoft-prod.rpm
#2.58.0-1.el8 at time of writing
dnf install -y azure-cli 

#Install alternative Python with incompatibilities
dnf install -y wget gcc make zlib-devel
wget 'https://www.python.org/ftp/python/3.9.18/Python-3.9.18.tgz'
tar -xf Python-*
cd Python-3.9.18
./configure --prefix=/tmp/python39 #No SSL support on purpose
make
make install

#Works as expected using system Python
az

#Fails because az wrapper runs alternative python with incompatibilities
export PATH=/tmp/python39/bin/:$PATH
az

Errors

N/A

Issue script & Debug output

N/A

Expected behavior

az / azure-cli to function even when the first python in PATH is set to an alternative Python install

Environment Summary

azure-cli 2.58.0-1.el8

Additional context

No response

[yonzhan]

Thank you for opening this issue, we will look into it.

[bebound]

az requires Python 3.9. If you've prioritized a newer Python 3.9 installation in your PATH over the system's default Python, then az should use new python3.9.
This follows standard practice in Linux environments.

[msftvito]

Thanks for replying Hang. The issue isn't a newer or older version, but a completely separate install that may not have all the dependencies or build options that azure-cli needs, like in the example I gave, the alternative python was built without SSL support. That's just a frivolous example that was easy to reproduce, but we may have cases like conflicting package requirements, etc.

…

________________________________ From: Hang ***@***.***> Sent: Sunday, March 10, 2024 7:53 PM To: Azure/azure-cli ***@***.***> Cc: Victor Tong ***@***.***>; Author ***@***.***> Subject: Re: [Azure/azure-cli] /usr/bin/az wrapper does not account for environments where an alternate python is used (RHEL8) (Issue #28530) az requires Python 3.9. If you've prioritized a newer Python 3.9 installation in your PATH over the system's default Python, then az should use new python3.9. This follows standard practice in Linux environments. — Reply to this email directly, view it on GitHub<#28530 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AURCPKJA7KQ2PDKPPPIDAX3YXUMB5AVCNFSM6AAAAABENIZ57CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOBXGUZTINZWGM>. You are receiving this because you authored the thread.

[bebound]

I stand by my point.

Regarding your issue, you can prioritize your own az which uses a hardcoded path.

[msftvito]

Hello Hang, am I understanding correctly that you do not see this as a problem and therefore will not fix it?

…

________________________________ From: Hang ***@***.***> Sent: Monday, March 11, 2024 6:38 PM To: Azure/azure-cli ***@***.***> Cc: Victor Tong ***@***.***>; Author ***@***.***> Subject: Re: [Azure/azure-cli] /usr/bin/az wrapper does not account for environments where an alternate python is used (RHEL8) (Issue #28530) I stand by my point. Regarding your issue, you can prioritize your own az which uses a hardcoded path. — Reply to this email directly, view it on GitHub<#28530 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AURCPKISJLIYUTPNPWOOSNDYXZMCXAVCNFSM6AAAAABENIZ57CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOBZG42TSMJSGE>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[bebound]

Yes

[msftvito]

OK, I still believe this is an issue best solved from your end, but if you are unwilling to work on it, I do not have the power to force you to.

…

________________________________ From: Hang ***@***.***> Sent: Tuesday, March 12, 2024 7:59 PM To: Azure/azure-cli ***@***.***> Cc: Victor Tong ***@***.***>; Author ***@***.***> Subject: Re: [Azure/azure-cli] /usr/bin/az wrapper does not account for environments where an alternate python is used (RHEL8) (Issue #28530) Yes — Reply to this email directly, view it on GitHub<#28530 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AURCPKPWZXYXTNVM3MUWTW3YX66KTAVCNFSM6AAAAABENIZ57CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOJTGI2TANJSG4>. You are receiving this because you authored the thread.Message ID: ***@***.***>