Unable to install/build the llvmlite package
#6281
Labels
question
Asking for clarification or support
Comments
|
Thanks, will take a look. |
|
What's the result of running |
|
|
It's very likely a problem with the package itself then. I'm having trouble reproducing this because that llvmlite version requires a very old LLVM, and newer versions work fine: Can you try setting |
|
Hmm, maybe I am doing something wrong? This is the full output of the actual command:
OutputFor some reason, |
|
I am not sure if this is an I was able to fix it by pinning the numba version to |
|
I have a similar problem to you @joennlae with the llvm version. I would prefer not installing this old llvm version and it would be impossible to get my whole student team to do it 😅 edit: I believe |
|
@joennlae @charliermarsh Unless I am using
I guess one other difference is that I am using the |
|
Does |
|
No, |
|
@taranlu-houzz -- Just to clarify, in your previous message, you used |
|
I replaced the name of the actual package with |
|
Same on Resolved 174 packages in 125ms
error: Failed to prepare distributions
Caused by: Failed to fetch wheel: llvmlite==0.34.0
Caused by: Build backend failed to build wheel through `build_wheel()` with exit code: 1
--- stdout:
running bdist_wheel
C:\Users\alex\AppData\Local\uv\cache\builds-v0\.tmptz0R7c\Scripts\python.exe C:\Users\alex\AppData\Local\uv\cache\built-wheels-v3\pypi\llvmlite\0.34.0\aL2IMNnikQ99dItFJEjv2\llvmlite-0.34.0.tar.gz\ffi\build.py
Trying generator 'Visual Studio 15 2017 Win64'
--- stderr:
Traceback (most recent call last):
File "C:\Users\alex\AppData\Local\uv\cache\built-wheels-v3\pypi\llvmlite\0.34.0\aL2IMNnikQ99dItFJEjv2\llvmlite-0.34.0.tar.gz\ffi\build.py", line 191, in <module>
main()
File "C:\Users\alex\AppData\Local\uv\cache\built-wheels-v3\pypi\llvmlite\0.34.0\aL2IMNnikQ99dItFJEjv2\llvmlite-0.34.0.tar.gz\ffi\build.py", line 179, in main
main_win32()
File "C:\Users\alex\AppData\Local\uv\cache\built-wheels-v3\pypi\llvmlite\0.34.0\aL2IMNnikQ99dItFJEjv2\llvmlite-0.34.0.tar.gz\ffi\build.py", line 88, in main_win32
generator = find_win32_generator()
^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\alex\AppData\Local\uv\cache\built-wheels-v3\pypi\llvmlite\0.34.0\aL2IMNnikQ99dItFJEjv2\llvmlite-0.34.0.tar.gz\ffi\build.py", line 76, in find_win32_generator
try_cmake(cmake_dir, build_dir, generator)
File "C:\Users\alex\AppData\Local\uv\cache\built-wheels-v3\pypi\llvmlite\0.34.0\aL2IMNnikQ99dItFJEjv2\llvmlite-0.34.0.tar.gz\ffi\build.py", line 28, in try_cmake
subprocess.check_call(['cmake', '-G', generator, cmake_dir])
File "C:\Users\alex\AppData\Local\Programs\Python\Python311\Lib\subprocess.py", line 408, in check_call
retcode = call(*popenargs, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\alex\AppData\Local\Programs\Python\Python311\Lib\subprocess.py", line 389, in call
with Popen(*popenargs, **kwargs) as p:
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\alex\AppData\Local\Programs\Python\Python311\Lib\subprocess.py", line 1026, in __init__
self._execute_child(args, executable, preexec_fn, close_fds,
File "C:\Users\alex\AppData\Local\Programs\Python\Python311\Lib\subprocess.py", line 1538, in _execute_child
hp, ht, pid, tid = _winapi.CreateProcess(executable, args,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
FileNotFoundError: [WinError 2] The system cannot find the file specified
error: command 'C:\\Users\\alex\\AppData\\Local\\uv\\cache\\builds-v0\\.tmptz0R7c\\Scripts\\python.exe' failed with exit code 1
This is my first use of |
|
Had this same behaviour where These dependencies were resolvable with poetry (I'm migrating). Tried to recreate with a smaller project without success Solution was to explicitly add |
|
👍 @derek-pyne you can also use to add a constraint without adding it as a dependency of your project. |
|
ahhh, even better! |
|
@zanieb That is a cool feature, but I think this may still be a bug. Is there a way to apply your suggestion when using |
|
If you run |
|
@charliermarsh So, this is the dep tree (via I would think that the version requirements of |
|
Is it possible that |
|
Can you run uv with |
|
Yes, that is what the output in this post is from: #6281 (comment)
At the time, I think I was using either |
|
Thanks! It's roughly what I was describing above... With that set of dependencies, we end up solving for In the absence of more constraints from the user, both resolutions are valid. We can't really "know" that you would prefer a more recent I might suggest adding |
|
My story: So my python version is
So it jumped down to |
|
@charliermarsh Ah, okay, I think that makes sense. Can the constraints file be used directly with the |
|
@taranlu-houzz -- You can pass the file like |
|
@charliermarsh Sort of a follow-up to this: Is it possible to layer on addition deps to an already installed tool using the method you mentioned above? For example, I have installed For one of my projects, I have an additional dep on |
|
I think |
|
@charliermarsh I'm guessing that it throws out the venv and creates a new one with the specified requirements and runs the tool using that (but that disregards the additional packages from the initial tool installation): |
|
Sorry, yes, I think that's right. We don't reuse an installed tool if that tool environment doesn't satisfy the request (i.e., |
|
Hmm, I don't know if it would really be better to allow for that added complexity... Maybe a different workflow would be better on my end. I was mainly just investigating some options for pulling more project dev deps into a single, unified location. |
This was referenced Oct 2, 2024
eginhard
added a commit
to idiap/coqui-ai-TTS
that referenced
this issue
Oct 20, 2024
Otherwise it backtracks to an old numba and then llvmlite version that can't be built: astral-sh/uv#6281
eginhard
added a commit
to idiap/coqui-ai-TTS
that referenced
this issue
Oct 20, 2024
Otherwise it backtracks to an old numba and then llvmlite version that can't be built: astral-sh/uv#6281
eginhard
added a commit
to idiap/coqui-ai-TTS
that referenced
this issue
Oct 20, 2024
Otherwise it backtracks to an old numba and then llvmlite version that can't be built: astral-sh/uv#6281
eginhard
added a commit
to idiap/coqui-ai-TTS
that referenced
this issue
Nov 4, 2024
Otherwise it backtracks to an old numba and then llvmlite version that can't be built: astral-sh/uv#6281
|
I ran into this issue when trying to install |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I ran into this while trying to install an internal package from a private repo that has a dep (or rather, dep of a dep, etc.) on
llvmlite. I am able to successfully install the package when usingpipx, butuvfails to install it.It seems like the issue occurs when trying to install the
llvmlitepackage, which it tries to build (the error below is a little different than the initial error).Platform:
macOS 14.6 (23G80)uv version:
uv 0.3.0 (dd1934c9c 2024-08-20)The text was updated successfully, but these errors were encountered: