SP_DIR vs. freethreading builds: wrong path?

[h-vetinari]

If I install

conda install -c conda-forge python-freethreading numpy

what gets populated is

$PREFIX/lib/python3.13t/site-packages/{numpy,...}  # including all the built-in imports
$PREFIX/lib/python3.13/site-packages/pip           # and presumably other noarch packages

However, when trying to build something on top (e.g. scipy), SP_DIR for the free-threading builds doesn't match the main site-package directory (python3.13 instead of python3.13t) and so the build fails¹

Not sure what's the best approach here, but my understanding would be that this is simply a bug that SP_DIR needs to reflect the t for freethreading builds.

CC @isuruf @jjhelmus

Footnotes

1. I'm not talking about the pip install, which works fine (and installs into python3.13t), but we need to manually copy something to $SP_DIR/scipy, due to the way the tests get split off into their own package. ↩

[rgommers]

A note for those who, like me, weren't familiar with this environment variable. It is set at build time and is the documented way to retrieve Python's site-packages location: https://docs.conda.io/projects/conda-build/en/stable/user-guide/environment-variables.html#environment-variables-set-during-the-build-process.

It's set here:

conda-build/conda_build/utils.py

Line 1001 in ad762d6

def get_site_packages(prefix, py_ver):

I agree with the assessment that it's a bug and the t should be added when a free-threading interpreter is used. It'd be nice to get a confirmation from a maintainer here.

[jschueller]

I'm running into the same problem for nlopt recipe