New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No module named azure in pyvenv #3989

Open
jaraco opened this Issue Jul 7, 2017 · 7 comments

Comments

6 participants
@jaraco
Copy link

jaraco commented Jul 7, 2017

Description

Installing azure-cli to a Python 3 venv produces invalid az command.

$ python3.6 -m venv ~/azure
$ ~/azure/bin/pip install -q azure-cli
$ ~/azure/bin/python --version        
Python 3.6.1
$ ~/azure/bin/az
/usr/local/opt/python/bin/python2.7: No module named azure

Whatever magic the az script is attempting to do is apparently not detecting the virtual environment and is instead invoking an old Python from a different environment where azure is not installed.

It's possible this installation method isn't supported, but as a Python engineer, I would have expected it to work.


Environment summary

Install Method: How did you install the CLI? (e.g. pip, interactive script, apt-get, Docker, MSI, nightly)
Answer here: pip

CLI Version: What version of the CLI and modules are installed? (Use az --version)
Answer here: 2.0.10

OS Version: What OS and version are you using?
Answer here: macOS 10.12.5

Shell Type: What shell are you using? (e.g. bash, cmd.exe, Bash on Windows)
Answer here: zsh

@troydai troydai added the Packaging label Jul 7, 2017

@troydai

This comment has been minimized.

Copy link
Contributor

troydai commented Jul 7, 2017

@derekbekoe

This comment has been minimized.

Copy link
Member

derekbekoe commented Jul 7, 2017

python -m azure.cli --version

What Python path does that refer to?

Also, does /usr/local/opt/python/bin/python2.7 contain a different installation of the CLI?

This may be to do with the code in https://github.com/Azure/azure-cli/blob/master/src/azure-cli/az.

@troydai

This comment has been minimized.

Copy link
Contributor

troydai commented Jul 7, 2017

The az script executes the python on the PATH, which I assume is 2.7. To make the az aware of the virtual environment some logics are required to find the correct python executable.

@jaraco you expect this work, so I assume there are precedents of other PIP installed applications to be aware of its virtual environment. Could you please point us to an example?

@jaraco

This comment has been minimized.

Copy link
Author

jaraco commented Jul 8, 2017

What Python path does that refer to?

I have python aliased to python3 because I use Python 3 by default even though the system Python is python2.7.

$ which python
python: aliased to python3
$ which python3
/Library/Frameworks/Python.framework/Versions/3.6/bin/python3

Python 3.6 is the stock python.org Python 3.6.1.

The only installation of the Azure CLI is in that virtualenv, so it's not installed to /usr/local/opt/python/bin/python2.7.

This may be to do with the code in az

Yes, almost certainly. I wonder if the invocation should be /usr/bin/env python -m. I'll test that.

@jaraco

This comment has been minimized.

Copy link
Author

jaraco commented Jul 8, 2017

Using /usr/bin/env python doesn't work either. Replacing it with $DIR/python does work, however:

$ sed -i -e 's|python |$DIR/python |' /opt/azure-env/bin/az
$ /opt/azure-env/bin/az --version | head -n 1
azure-cli (2.0.10)
@hemake

This comment has been minimized.

Copy link
Member

hemake commented Jan 4, 2018

I have both python and python3 environments installed. Chose toinstall azure-cli to python3. Even if you have alias pointing python to python3 did not help. The command $ cat $(which az) @derekbekoe pointed out solved the issue. In my case I edit the az file as simply changing the python in the last line to python3:

#!/bin/bash

SOURCE="${BASH_SOURCE[0]}"
while [ -h "$SOURCE" ]; do # resolve $SOURCE until the file is no longer a symlink
  DIR="$( cd -P "$( dirname "$SOURCE" )" && pwd )"
  SOURCE="$(readlink "$SOURCE")"
  [[ $SOURCE != /* ]] && SOURCE="$DIR/$SOURCE" # if $SOURCE was a relative symlink, we need to resolve it relative to the path where the symlink file was located
done
DIR="$( cd -P "$( dirname "$SOURCE" )" && pwd )"

export PYTHONPATH="${DIR}/src:${PYTHONPATH}"

python3 -m azure.cli "$@"

python3 above will automatically point to /usr/bin/python3 and solved the issue.

@pedrohdz

This comment has been minimized.

Copy link

pedrohdz commented Feb 9, 2019

Per the distutils documentation:

Scripts are files containing Python source code, intended to be started from the command line. Scripts don’t require Distutils to do anything very complicated. The only clever feature is that if the first line of the script starts with #! and contains the word “python”, the Distutils will adjust the first line to refer to the current interpreter location. By default, it is replaced with the current interpreter location. The --executable (or -e) option will allow the interpreter path to be explicitly overridden.

So scripts in azure-cli/src/azure-cli/setup.py is being misused to install a bash shell script when the Python documentation states "Scripts are files containing Python source code". This does not allow Distutils to "adjust the first line to refer to the current interpreter location", hence breaking the whole thing. Granted, the "if in "if the first line of the script starts with #! and contains the word 'python'" makes it optional.

So @jaraco's solution is the best work around at the moment.

This is the only Python package I have come across that has this problem.

Maybe some extra logic in azure-cli/src/azure-cli/az would resolve the issue allowing people to install azure-cli in a venv without post installation modification is the correct solution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment