Bug: simsimd-6.2.1-cp313-cp313-manylinux_2_28_x86_64.whl contains folder "simsimd." that is failed to be extracted in Linux under NTFS
Describe the bug
Hello, trying to install this package with uv --reinstall. It turns out, uv tries to extract whole whl file. The archive contains "simsimd." folder with trailing dot. Such folder naming is prohibited on Ubuntu under NTFS (shared volume). So it breaks installation flow.
Could you have a look and fix it?
Steps to reproduce
On NTFS volume:
mkdir reproduce && cd reproduce
uv venv --prompt reproduce --python 3.11 .venv
source .venv/bin/activate
uv pip install simsimd==6.2.1 --reinstall
I'm getting the following error, though I'd expect it to be installed
Resolved 1 package in 52ms
Prepared 1 package in 0.19ms
error: Failed to install: simsimd-6.2.1-cp311-cp311-manylinux_2_28_x86_64.whl (simsimd==6.2.1)
Caused by: failed to create directory `/media/smileijp/NVMe/projects/invoke/reproduce/.venv/lib/python3.11/site-packages/simsimd.`: Invalid argument (os error 22)
Expected behavior
Package should be installed
SimSIMD version
v6.2.1
Operating System
Ubuntu 22.04.4 LTS
Hardware architecture
x86
Which interface are you using?
Python bindings
Contact Details
Are you open to being tagged as a contributor?
- [x] I am open to being mentioned in the project
.githistory as a contributor
Is there an existing issue for this?
- [x] I have searched the existing issues
Code of Conduct
- [x] I agree to follow this project's Code of Conduct
Also, listing the content of whl
(reproduce) smileijp@desktop-smile:/media/smileijp/NVMe/projects/invoke/sandbox$ unzip -l simsimd-6.2.1-cp313-cp313-manylinux_2_28_x86_64.whl
Archive: simsimd-6.2.1-cp313-cp313-manylinux_2_28_x86_64.whl
Length Date Time Name
--------- ---------- ----- ----
0 2024-11-27 12:45 simsimd-6.2.1.dist-info/
0 2024-11-27 12:45 simsimd/
0 2024-11-27 12:45 simsimd./
1858593 2024-11-27 12:45 simsimd.cpython-313-x86_64-linux-gnu.so
8 2024-11-27 12:45 simsimd-6.2.1.dist-info/top_level.txt
736 2024-11-27 12:45 simsimd-6.2.1.dist-info/RECORD
11357 2024-11-27 12:45 simsimd-6.2.1.dist-info/LICENSE
66010 2024-11-27 12:45 simsimd-6.2.1.dist-info/METADATA
113 2024-11-27 12:45 simsimd-6.2.1.dist-info/WHEEL
9829 2024-11-27 12:45 simsimd/__init__.pyi
0 2024-11-27 12:45 simsimd/py.typed
253289 2024-11-27 12:45 simsimd./libgomp-24e2ab19.so.1.0.0
--------- -------
2199935 12 files
Interesting, will look into potential issues. In the meantime, if anyone else has an answer - I am all ears 🤗
@ashvardanian I bet the problem comes from here: https://github.com/ashvardanian/SimSIMD/blob/main/pyproject.toml#L60
If you check auditwheel, you can see they concatenate lib-sdir (default: .libs) to the name of the package. If you use dot, it will be a dot.
https://github.com/pypa/auditwheel/blob/3e4b6b3fdaf38f5da94d8212542fd7f6138c3b80/src/auditwheel/repair.py#L68
I'd assume if you'll remove "--lib-sdir .", it should fix a problem.
Can be the case! I'm away from the PC now, but if you submit a PR, would be happy to merge it from the phone 🤗
I'm not sure I'll be able to build it quickly. Some issues with gcc and avx512fp16.
You may want to upgrade GCC or disable AVX512FP16 through CMake options.
Hi @vsevolod-oparin! Does the issue repeat with the newer 6.4.7?
I also get the issue with simsimd-6.4.9-cp312-cp312-manylinux_2_28_x86_64.whl. Same situation of using an ntfs3 drive, though I suspect the simsimd. with trailing dot is unintended.
I have the same issue :
error: Failed to install: simsimd-6.5.0-cp312-cp312-manylinux_2_24_x86_64.manylinux_2_28_x86_64.whl (simsimd==6.5.0)
Caused by: failed to create directory ./.venv/lib/python3.12/site-packages/simsimd.: Invalid argument (os error 22)
Have you tried removing "--lib-sdir ." ? SimSIMD is now a dependency to many other packages, including usearch, so this bug would affect many others too, i guess.
Can't recall if I've tried that. But in any case, isn't the dot path a valid argument according to docs?
I can merge if someone can draft a solution 🤗
I tried removing "--lib-sdir .", then reinstalling from the source code, and it worked on NTFS.
I am scared of breaking the Linux CI with that change. I can try it a bit later 🤗