[3.7] Build against libxcrypt on Linux

[AaronOpfer]

Creating this PR as was suggested in discussion in conda-forge/linux-sysroot-feedstock#52, modeled after other PRs along the same vein from @mbargull .

refs:

#664
conda-forge/linux-sysroot-feedstock#52

Checklist

• Used a personal fork of the feedstock to propose changes
• Bumped the build number (if the version is unchanged)
• Reset the build number to 0 (if the version changed)
• Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• Ensured the license file is being packaged.

[conda-forge-webservices]

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) and found it was in an excellent condition.

[jakirkham]

Thanks Aaron! 🙏

Would suggest adding the text below to conda-forge.yml's azure section and re-render

python-feedstock/conda-forge.yml

Line 11 in b850a59

azure:

azure:
  settings_win:
    pool:
      vmImage: vs2017-win2016

[AaronOpfer]

Gave that a try, but seems like no luck. @jakirkham

[jakirkham]

Thanks Aaron! 🙏

Provided another potential option below. Let's see if that works better

[jakirkham]

@beckermr , just to confirm, is this what we want here? Is there anything else we need?

[beckermr]

Assuming it has a proper run export, this should be everything.

[beckermr]

@mbargull already converted the current python versions so you can compare to that recipe to be sure.

[jakirkham]

That looks like what Marcel did in PR: #664

Though would be happy to hear feedback from him

Looks like we already cover the import crypt test case

python-feedstock/recipe/run_test.py

Line 80 in d9b57b0

import crypt

[mbargull]

I'm not against rebuilding against libxcrypt.
However, rebuilding this against an updated global pinning is probably not what would @AaronOpfer and others help.
We do not rebuild packages that depend on Python 3.6/3.7 anymore, which means that if we only rebuild conda-forge::python=3.6,3.7, we'll likely add updated dependency constraints which would be incompatible with Python extension modules on conda-forge that have been built against the same packages but only in older versions.
(Looking at the changes to .ci_support/*.yaml here, it doesn't look like much has changed, apart from the dropped openssl=1.1.1 builds; but there could still be things like tightened run_exports in some of the dependencies -- i.e., someone should look at the actual constraints generated.)

Meaning, we might not want a full rerendering here to try to build against older libs (and have someone verify this by comparing with previous python=3.6,3.7 builds).

So, to me libcrypt/libxcrypt is actually not the most important thing we should look out for here, but rather the other dependencies.

(FYI, Aaron's issue does probably not concern the actual linked libcrypt at all, but rather the fact that Python.h includes crypt.h for Python <=3.8; in >=3.9 it is only used for the crypt module and in >=3.13 it will not be used at all.)

[jakirkham]

That's a good point Marcel!

We can revert the bulk of the variant changes (though some things like the Visual Studio version are out of our hands)

Also if you haven't already, please read over this discussion for more context: conda-forge/linux-sysroot-feedstock#52 (comment)

[AaronOpfer]

Thanks for the feedback. I was also concerned about creating a variant that does not fit the same role as the last built py37. FWIW, I have consulted with my users and discovered they are still using the openssl 1.1.1 variant of Python 3.7.12, so discarding that variant would be suboptimal.

I'm very much new to the conda feedstock system still. Do we believe we would fix this by modifying the recipe/conda_build_config.yaml and rerendering as the .ci_support/README suggests? Or would we hand-edit the files as we're doing artifact archeology on an old recipe?

[AaronOpfer]

One more note: if CF maintainers would like to take over and directly edit this PR instead of puppeteering this conda-feedstock novice, please feel free to do so 🙂

[jakirkham]

I have consulted with my users and discovered they are still using the openssl 1.1.1 variant of Python 3.7.12

Um I hope not. OpenSSL 1.1.1 has already reached EOL

Do we believe we would fix this by modifying the recipe/conda_build_config.yaml and rerendering as the .ci_support/README suggests? Or would we hand-edit the files as we're doing artifact archeology on an old recipe?

Was thinking we could just

git checkout 3.7 -- .ci_support
git add .ci_support
git commit -m 'Restore `.ci_support` from `3.7`'

[h-vetinari]

Um I hope not. OpenSSL 1.1.1 has already reached EOL

Python 3.7 never officially gained support for OpenSSL 3. We only did that in conda-forge.

[AaronOpfer]

OK; all builds are green. The remaining question is: how do we inspect the resulting packages runtime data to make sure they're matching or reasonably close to matching the original Python 3.7.12 builds?

[h-vetinari]

Wouldn't we also need to match the pins for previous pin_run_as_build packages to "period-appropriate" versions in the local CBC?

[AaronOpfer]

FYI, my company no longer needs this urgently. We ended up hacking up references to the old sysroot_linux-64 for py36 and py37 targets since I tried to get the ball rolling a few weeks ago.