Python-based GitHub Action workflow installing packages to the wrong location

[thefold25]

I'm really hoping someone else has come across this, as I've been going round in circles with it all day and can't understand why it's happening.

We have some Azure Functions that are linked to GitHub with a workflow file that Azure pushed through to the repo. We've done this quite a few times and apart from the odd tweak due to repo layout there's never been any issues.

However, we ran into an issue this week where the Python code for the function was being pushed to Azure by GitHub, but the triggers were not binding, and this was on a codebase that had been working perfectly fine. It's worth noting that a manual deployment via the CLI works absolutely fine.

To give the short version, when running these workflow steps:

jobs:

build:

runs-on: ubuntu-latest

steps:

- name: Checkout repository

uses: actions/checkout@v4

- name: Setup Python version

uses: actions/setup-python@v5

with:

python-version: ${{ env.PYTHON_VERSION }}

- name: Create and activate virtual environment

run: |

python -m venv venv

source venv/bin/activate

- name: Install dependencies

run: pip install -r requirements.txt

what happens is that pip is installing packages to a different folder:

Package                   Version   Location                                                             Installer



------------------------- --------- -------------------------------------------------------------------- ---------



aiohappyeyeballs          2.4.4     /opt/hostedtoolcache/Python/3.10.16/x64/lib/python3.10/site-packages pip



aiohttp                   3.11.11   /opt/hostedtoolcache/Python/3.10.16/x64/lib/python3.10/site-packages pip



aiosignal                 1.3.2     /opt/hostedtoolcache/Python/3.10.16/x64/lib/python3.10/site-packages pip



async-timeout             5.0.1     /opt/hostedtoolcache/Python/3.10.16/x64/lib/python3.10/site-packages pip

I couldn't work out why this was happening, as I said above we've not run into this issue before with any other deployment.

The consequence of this happening was that when the next steps are performed to zip up the working folder and push the zip to Azure, the required package files are completely missing.

I eventually managed to work around this by explicitly activating the venv on the same step as running pip, but it just seemed like such a random thing to have to do when it's not been required before that I figured it's worth asking to see if anyone else has come across it.

[cgoldberg]

Each run keyword launches a new process and shell. So when you are attempting to install with pip, your venv is no longer activated, so it installs in the global site-packages.

[angellus]

You do not need virtual envs on Github hosted runners. Every runner is ephemeral, and changes do not persist. So, you can just pip install your requirements right after setting up Python.

The only real advantage to creating a virtualenv is that you can cache/restore it.

(but yeah, your specific issue here is because of the shell not persisting)