-
Notifications
You must be signed in to change notification settings - Fork 423
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Encoding python runtime variant in build string #4252
Comments
Now that anaconda hired the pyston devs, this is going to become more relevant here as well. :) |
Hi there, thank you for your contribution! This issue has been automatically marked as stale because it has not had recent activity. It will be closed automatically if no further activity occurs. If you would like this issue to remain open please:
NOTE: If this issue was closed prematurely, please leave a comment. Thanks! |
Ah damn, missed the initial ping here. Could this be reopened please? |
@mbargull @kenodegard @jezdez @beeankha could someone reopen this issue please? |
Currently, the default
CONDA_PY
in the build string resolves topy37
for both cpython & pypy. It would help IMO to see immediately from the artefact name for which python variant a package has been built.Example for a current numpy build (using
pypy37
instead ofpy37
for the pypy variant)linux-64/numpy-1.21.1-py37h038b26d_0.tar.bz2
linux-64/numpy-1.21.1-py37h620df1f_0.tar.bz2
-->linux-64/numpy-1.21.1-pypy37h620df1f_0.tar.bz2
This would also apply if conda-forge ever packages other runtimes, e.g. conda-forge/staged-recipes#13019
Since defaults doesn't distribute pypy, I originally considered this more of a conda-forge problem and had opened conda-forge/conda-forge.github.io#1479, but was then asked to open the issue here.
The text was updated successfully, but these errors were encountered: