0

I want to deploy a python script with a virtual environment (I need a library which is not in the runtime provided by IBM Cloud Functions) to IBM Cloud Functions. I want to do this with simple zipping so I followed the documentation: Packaging Python code with a local virtual environment in a compressed file in the link below: https://cloud.ibm.com/docs/openwhisk?topic=openwhisk-prep

I have python 3.7 installed and the virtualenv also uses that. The virtualenv is named "virtualenv" as required, however I still receive the error when I try to invoke the action: Results:

{
  "error": "The action failed to generate or locate a binary. See logs for details."
}
Logs:
[
  "2021-05-20T09:27:03.627094Z    stderr: Invalid virtualenv. Zip file does not include activate_this.py",
  "2021-05-20T09:27:03.627Z       stderr: The action did not initialize or run as expected. Log data might be missing."
]

I checked the virtualenv directory and I have "activate_this.py" in the Scripts folder.

What am I missing? The only difference between the steps I take and the documentation is that I have a windows computer, so the activation of the environment went like virtualenv\Scripts\activate, not through bin, and I zipped the script and the virtualenv via windows GUI.

Is it possible that Cloud Functions tries to find the file in a "bin" folder instead of a "Scripts"? If so, what can I do?

Thanks

Looz
  • 377
  • 2
  • 14
  • It's very much possible Cloud Functions is only looking in `bin`. – AKX May 20 '21 at 10:33
  • How should I deploy something from Windows then? – Looz May 20 '21 at 10:34
  • You could see what happens if you rename the Scripts folder within the zip to bin. With any luck, it might just work. – AKX May 20 '21 at 10:36
  • The docs also mention that using Docker might be easier. https://cloud.ibm.com/docs/openwhisk?topic=openwhisk-prep#prep_python_virtenv – AKX May 20 '21 at 10:37
  • Im not familiar with docker, do you think if I use the same windows virtualenv in a docker image it will work? BTW overwriting the scripts folder to bin worked. now it has issues finding the library needed to run the script. Do you know the folder structure in a linux virtualenv? In windows I have: virtualenv\Lib\site-packages\ How should I overwrite these folder names? – Looz May 20 '21 at 10:43
  • You'd just install the dependencies "raw" in to a base Python Docker image, without a virtualenv in the way. On Linux, there's an additional `pythonX.Y` directory within `site-packages` – but you'll still have a bad time if there are any binary dependencies within that Windows site-packages directory, since those won't run on other OSes. – AKX May 20 '21 at 10:44
  • Then I'll stop this overwriting folder's method. I still do not get the Docker part unfortunately, the documentation mentions virtual environments still with this solution. #5 Create a virtual environment and install the additional Python packages. Can this still work? – Looz May 20 '21 at 10:54
  • Ah, I didn't read the instructions through. They're using Docker to build an IBM Cloud compatible virtualenv that's then "returned" to your host system, so you can paste in your code and zip it up. That's a little wonky but certainly more OS agnostic. – AKX May 20 '21 at 10:56
  • So that is something worth trying even if I'm on Windows and the virtualenv structure will be different from the Linux one? – Looz May 20 '21 at 10:59
  • The docker process will create a linux-type virtualenv that you can zip up. Your local Windows development virtualenv will be different. – AKX May 20 '21 at 11:01
  • I just worked it around as I am a simple man lol. I copied the dependency library folders from site-packages directly to the root next to __main__.py, deleted the whole virtualenv folder and it works like a charm. Thanks for your tips mate! – Looz May 20 '21 at 11:12

1 Answers1

0

This is a bug in handling windows packaged venv, as you noted. It is fixed in this fork https://github.com/nimbella-corp/openwhisk-runtime-python/commit/2eb3422cb2dca291cff47ed3239de8512170a1be you can apply and build your own container image as a workaround.

user6062970
  • 831
  • 4
  • 5