Azure Web Apps fail to install Azure-Storage 0.33.0

Hello, issue is easily reproduceable: Create a flask web app add azure-storage to requirements.txt and try to push it to the Web App… It will fail with 2.7 and 3.4. See attached log file.

Running setup.py install for cryptography
BLA-BLA-BLA
remote: distutils.errors.DistutilsError: Setup script exited with error: Unable to find vcvarsall.bat
remote:
remote: ----------------------------------------
remote: Cleaning up...
remote: .........................
remote: Command D:\home\site\wwwroot\env\Scripts\python.exe -c "import setuptools, tokenize;__file__='D:\\home\\site\\wwwroot\\env\\build\\cryptography\\setup.py';exec(compile(getattr(tokenize, 'open', open)(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" install --record D:\local\Temp\pip-1tk19zep-record\install-record.txt --single-version-externally-managed --compile --install-headers D:\home\site\wwwroot\env\include\site\python3.4 failed with error code 1 in D:\home\site\wwwroot\env\build\cryptography
remote: Storing debug log for failure in D:\home\pip\pip.log
remote: An error has occurred during web site deployment.

You owe me a couple of days of my life 😦 So it works for any version without that stupid broken cryptography.

fail.txt

[tadashiee]

I encountered this problem, too. But, I found the workarround of this problem . I describe our environment, problem, primary cause, and workarround below: [[ Environment ]] ** Azure Web Apps ** python 3.4.1 (32bit) ** My development PC **

• Windows 7 (32bit)
• python 3.4.1 (32bit) pip (1.5.6) setuptools (2.1)
• wheel packages in the ‘wheelhouse’ directory azure_common-1.1.4-py2.py3-none-any.whl azure_nspkg-1.0.0-py2.py3-none-any.whl azure_storage-0.33.0-py3-none-any.whl cffi-1.9.1-cp34-cp34m-win32.whl cryptography-1.7.1-cp34-cp34m-win32.whl idna-2.2-py2.py3-none-any.whl pyasn1-0.1.9-py2.py3-none-any.whl pycparser-2.17-py2.py3-none-any.whl python_dateutil-2.6.0-py2.py3-none-any.whl requests-2.12.4-py2.py3-none-any.whl setuptools-32.3.1-py2.py3-none-any.whl six-1.10.0-py2.py3-none-any.whl
• description of requirements.txt ±------------------------------------------ |–no-index --find-links wheelhouse |azure-nspkg==1.0.0 |azure-common==1.1.4 | : | (omit) | : ±------------------------------------------

[[ Problem]] The wheel package registered in the git repository fails in the installation on the Azure environment.

[[ Primary cause ]] on Python 3.4 of Azure Web Apps, version of pip is 1.5.6 . pip (1.5.6) is not able to recognize ‘–find-links’ option which was written in the top of requirements.txt file.

[[ Workarround ]] Upgrade pip on Azure Web Apps, using ‘deploy.cmd’ file.

[[ Detail ]] At first, please refer to following URL. https://docs.microsoft.com/en-us/azure/app-service-web/web-sites-python-configure

I got default ‘.deployment’ file and ‘deploy.cmd’ file from Azure Web Apps Kudu Service. ** How to get these files **

1. Login to azure dashboard
2. Select Web Apps instance
3. Select [Advanced Tools] and view new page which title is ‘Kudu Services’
4. Select [Tools] at menu bar, and choose [Download deployment script] –> Save ‘deploymentscript.zip’ file into local.
5. Unzip deploymentscript.zip

and, please edit the vicinity of the following lines in ‘deploy.cmd’ . (before) echo Pip install requirements. env\scripts\pip install -r requirements.txt (after) echo Upgrade pip package. env\scripts\python -m pip install pip --upgrade IF !ERRORLEVEL! NEQ 0 goto error echo Pip install requirements. env\scripts\pip install -r requirements.txt

(* I also upgraded setuptools )

finally, please copy ‘.deployment’ and ‘deploy.cmd’ file onto top folder of GIT project, then commit/push it.

By this workarrownd, I successfully installed wheel format packages into Azure Web Apps. It would be greatly appreciated if this workarround is useful for you. (Please pardon a poor English expression)

[zooba]

The best solution is to upgrade the version of Python on app service by following the instructions at https://aka.ms/PythonOnAppService.

The version that is preinstalled is very old, but for backwards-compatibility reasons we cannot upgrade it, so instead we are deprecating use of the preinstalled version and recommending everyone use the site extensions described at the link above.

And yes, we intend to improve this process so it is simpler in the future, but until the App Service team is able to help us out (right now we have to fix it with only publicly-available APIs/features), there are going to be a few extra manual steps involved. Luckily, most of those just make the process more transparent, so it isn’t necessarily a bad thing, but it does complicate the process somewhat.