actually move python*.dll to libpython on windows

[h-vetinari]

Follow-up to #894. I noticed by chance that the python3.dll etc. did not actually end up in libpython.

That's despite tests to this effect

python-feedstock/recipe/meta.yaml

Lines 372 to 378 in 663c2af

	{% if freethreading == "yes" %}
	- if not exist %PREFIX%\python3t.dll exit 1 # [win]
	- if not exist %PREFIX%\python{{ ver2nd }}t.dll exit 1 # [win]
	{% else %}
	- if not exist %PREFIX%\python3.dll exit 1 # [win]
	- if not exist %PREFIX%\python{{ ver2nd }}.dll exit 1 # [win]
	{% endif %}

which however got satisfied spuriously by an additional test dependency

python-feedstock/recipe/meta.yaml

Lines 353 to 355 in 663c2af

	# build-and-test.sh needs to find `Python.h`; can't do pin_subpackage
	# due to the way conda-build (mis-)populates the package hashes
	- python {{ version }} *_{{ PKG_BUILDNUM }}{{ debug }}_{{ abi_tag }}

That dependency is a left-over from the libpython tests prior to the build order inversion in 636474b. Now those tests make no sense on the libpython output anymore (causing us to shoehorn the full-fledged python back in to find e.g. Python.h and the executables, which also hides problems with the file-presence tests), so move them to python.

[conda-forge-admin]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found it was in an excellent condition.

I do have some suggestions for making it better though...

For recipe/meta.yaml:

• ℹ️ The recipe is not parsable by parser conda-souschef (grayskull). This parser is not currently used by conda-forge, but may be in the future. We are collecting information to see which recipes are compatible with grayskull.
• ℹ️ The recipe is not parsable by parser conda-recipe-manager. The recipe can only be automatically migrated to the new v1 format if it is parseable by conda-recipe-manager.

_{This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/33116684592. Examine the logs at this URL for more detail.}

[h-vetinari]

@mgorny, could I ask you to review here? With 636474b, I don't think the tests for libpython make sense anymore as they were originally written, but I wanted to make sure I didn't misunderstand your original intent here.

[mgorny]

I'm pretty sure there was no special reason for that. Just a mistake made while splitting them.

[isuruf]

We should revert this PR. libpython is empty in dev branch and it should be empty because python.exe depends on it.

[h-vetinari]

We should revert this PR. libpython is empty in dev branch and it should be empty because python.exe depends on it.

It's reverted in #908. For 3.14 and below, python depends on libpython, so python.exe will always find the required DLLs.

[isuruf]

or 3.14 and below, python depends on libpython, so python.exe will always find the required DLLs.

Yes, but it's going to be odd that libpython had the DLL for previous versions and it doesn't for 3.15+

[h-vetinari]

If you want to revert this also for 3.14, then fine by me. I was just following your wishes, as well as I could interpret your comments. And you merged this PR, which I think was well-documented in terms of what it does...

[isuruf]

Not blaming you here. I just forgot this detail when reviewing this PR.