Build failing due to aiohttp, solution may change the env variable name

[apmorton]

Comment:

The latest version failed: e5b4a50 (despite passing in the PR)
This regro migration failed in the same way: #172

According to azure build logs:
Passing build was at: Jul 31 at 10:13 PM
Failing build was at: Aug 1 at 7:07 AM

Something changed between those two builds.

Raw logs for passing build: https://dev.azure.com/conda-forge/84710dde-1620-425b-80d0-4cf5baca359d/_apis/build/builds/992028/logs/65
Raw logs for failing build: https://dev.azure.com/conda-forge/84710dde-1620-425b-80d0-4cf5baca359d/_apis/build/builds/992337/logs/46

Near as I can tell the only difference between the passing and failing build before things go off the rails is:

-    conda-build version : 24.5.1
+    conda-build version : 24.7.1

I'll also note that we appear to be vendoring python modules in ray-core under lib/python3.10/site-packages/ray/_private/runtime_env/agent/thirdparty_files/, aiohttp included.

So it seems what's happening here is due to a conda-build change we aren't detecting the third-party bundled aiohttp anymore?

[apmorton]

From conda-build changelog:

PIP_* env variables are set when building outputs in multi-output recipes. (conda/conda-build#3993 via conda/conda-build#5368)

Seems like this is the change: conda/conda-build#5368

[mattip]

This was fixed via a patch in #176. I submitted an upstream PR to fix upstream as well, they requested I change the name of the skip variable to SKIP_THIRDPARTY_INSTALL_CONDA_FORGE. So the release that includes this change will require adapting the scripts here to set SKIP_THIRDPARTY_INSTALL_CONDA_FORGE=1