Azure-cli: az wrongly assumes Python executable

[akx]

Describe the bug

When installing azure-cli on Ubuntu 18.04 LTS with

# apt install python3-pip
# pip3 install azure-cli

the installed CLI does not work with az:

# az --version
/usr/bin/python: No module named azure
#

This is due to the fact that the az script assumes that python is the Python executable that can be used to import azure.cli. Due to PEP 394 – The "python" Command on Unix-Like Systems this may not be the case. (The gist of it is that Python 3 is expected to be installed as python3 in a system-wide context, while python remains Python 2, if installed.)

Running python3 -m azure.cli --version (which is what az should do) does work as expected.

To Reproduce

See above.

Expected behavior

az works without shenanigans.

Environment summary

• OS: Ubuntu 18.04 LTS
• Install method: See above.
• Shell: Bash 4.4.19
• python -m azure.cli --version: azure-cli (2.0.45)

Additional context

This problem would probably be fixed by using distutils entrypoints instead of a bespoke az shell script.

[akx]

Ah, this seems to be a duplicate of #1043 . . . Either way, leaving it open here as it provides further detail.

[pmarques]

@yugangw-msft Is this related to Debian or pip? wouldn't the tag Packaging/Pip be more accurate?

[aribornstein]

Is there any resolution I'm having the same issue my work around is to use the bash alias command

alias az='python3 -m azure.cli'

[marstr]

Looking at this issue's history, it's clear that there's been a lot of turbulence with how much of a priority this issue should be. But I think it hints at an internal struggle that we've had, which is answering the questions, "do we support pip install azure-cli?"

We've never officially said that we do, but we also make sure that the latest version is always published to PyPI. We've also changed design decisions to make sure that folks who install using pip have a coherent version of the CLI.

For me personally (not necessarily how my whole team feels), it's never seemed like a priority. I say that because as an application, I would think even which programming language was used should be largely opaque to the customer. I'd rather emphasize platform specific installers, like our MSI installer, and packages made for Linux package managers. It gives us a lot more control to provide idiomatic experiences for people in different environments, especially folks who are not Python developers.

Not saying that it isn't painful, or that it shouldn't be fixed. But hopefully this sheds some light on why this issue has never garnered much attention.

[marstr]

Another update, the team is in the middle of a shuffle. I don't believe I'll have time to work on this issue in the next week before I'm on a different team. For that reason, I'm going to unassign myself.

[uda]

It doesn't matter if you officially support pip install or not, I bet there is a reason the az script the way it does, but this is easily solvable by using the built-in entrypoints in setup.py, which should use which ever environment the user is using instead of making decisions for the user.

This should not affect the OS packaged installation.

[pmarques]

Apparently setuptools has some drawbacks accordingly to this PR #1042

[akx]

The perf drawbacks are easily mitigated with https://pypi.org/project/fastentrypoints/ .

[fengzhou-msft]

fixed by https://github.com/Azure/azure-cli/pull/10516, will release on 11/26