Open dhirschfeld opened 1 month ago
I naively added a constraint in the
pixi.toml
:
What you did should work, so that's probably an issue with a cached/non-empty build directory or some such thing.
More importantly though, the wheel produced by pixi run wheel
aren't meant to be portable to other environments/machines, so it's unlikely that you actually need this kind of wheel. If that's what you want, it needs an auditwheel
(or delocate
or delvewheel
) invocation in the command for the wheel
pixi task.
What you did should work, so that's probably an issue with a cached/non-empty build directory or some such thing.
I did a git clean -xfd
in both pixi-dev-scipystack
and pixi-dev-scipystack/scipy/scipy
and it still failed with the crypt.h
error. I would've assumed a missing dependency. Does a 3.10 build work for you with pixi-dev-scipystack
?
Yes, that works fine. I've tested both 3.10.0 and 3.10.14, all good. I was thinking perhaps you got 3.10.0, and the correct constraint is one of 3.10.*
or >=3.10,<3.11
- you can check with pixi ls python
. Either way it all works for me.
Thanks - it's good to know that it should work! Now I just need to figure out what I'm doing wrong... 😬
Googling turns up multiple instances of the missing crypt.h
error:
https://www.google.com/search?q=Python.h%3A44%3A10+fatal+error+%22crypt.h%22+%22No+such+file+or+directory%22
Which seems to suggest a missing libxcrypt
dependency. Specifying that package as a dep seemed to fix it for me:
Ah, I can reproduce it now - only with Python 3.10.0
on Linux (only had macOS at hand before). This is a curious case, looks like a bug in pixi
, but isn't. It seems to be related to https://github.com/conda-forge/linux-sysroot-feedstock/issues/52, but that should have only removed libcrypt
as a dependency for Python <3.9.
libxcrypt
is a dependency of Python 3.10 in conda-forge, more specifically 3.10.15. I checked in two ways, first by creating a new env with just python 3.10:
$ mamba create -n crypt python=3.10
$ mamba activate crypt
$ ls ~/mambaforge/envs/crypt/include/cryp*
/home/rgommers/mambaforge/envs/crypt/include/crypt.h
$ mamba repoquery whoneeds libxcrypt
...
Name Version Build Depends Channel
──────────────────────────────────────────────────────────────────
python 3.10.15 h4a871b0_2_cpython libxcrypt >=4.4.36 conda-forge
And then by looking at the metadata in https://prefix.dev/channels/conda-forge/packages/python:
I reproduced the bug by adding python = "3.10"
to pixi.toml
, which gives you 3.10.0
(a bit of a footgun) instead of 3.10.15
. When you then later update to "python = 3.10.*
you will still get 3.10.0
since the already-present 3.10.0 in the lock file satisfies that .*
. If instead you had used the .*
syntax from the start, you'd get 3.10.15
and that doesn't have this issue.
@dhirschfeld can you please ensure you get <3.10.15` installed and the problem goes away then?
pixi run wheel
builds a Python 3.12 wheel no problems. I need a Python 3.10 wheel though. How can I specify the Python version to build for?I naively added a constraint in the
pixi.toml
:...but that gave an error about a missing header file:
How can a build for a specific Python version?