Python pip installs fail - so many times - solution?

[Tracker]

Hi,

What's the solution to `pip install package` failing - usually there's some error like target of FreeBSD isn't supported or subprocess exited with some error ......... some of the packages install just fine but this is a major source of headache when you want to try out something in the Python world.

Is there some solution for this issue? Running pip packages is a pretty important requirement

PS: I also have linux_enable="YES" btw and the drivers loaded, and kldload shows linux drivers - in case that's of any consequence

 

[Tracker]

Or is the only solution to run some VM with linux/ubuntu? That's the only one that comes to mind

Also possibly changing the text in these from "freebsd" as target to something like "linux" - should get it to work perhaps

 

[ralphbsz]

or subprocess exited with some error

I can't help debug "some error". I can help debug concrete problems.

Seriously, there are some big issues with mixing pip and packages. But I have not experienced pip breaking with random errors that are hard to debug. The big issue is on operating systems where python installed are "locked down", meaning only the package manage system (pkg, apt, ...) is allowed to install python packages. That doesn't work in practice, because for many python things, OS packages are not available, so you have to bypass that protection. And afterwards you have to be very careful when upgrading things to not mix pip and pkg.

 

[Tracker]

I can't help debug "some error". I can help debug concrete problems.

How about this - usually something similar many a times with something to do with "freebsd"


pip install jupyter-ai[all]
Defaulting to user installation because normal site-packages is not writeable
Collecting jupyter-ai[all]
Using cached jupyter_ai-2.31.6-py3-none-any.whl.metadata (8.3 kB)
Collecting dask[distributed] (from jupyter-ai[all])
Using cached dask-2025.10.0-py3-none-any.whl.metadata (3.8 kB)
Collecting deepmerge<3,>=2.0 (from jupyter-ai[all])
Using cached deepmerge-2.0-py3-none-any.whl.metadata (3.5 kB)
Collecting faiss-cpu!=1.8.0.post0,<2.0.0,>=1.8.0 (from jupyter-ai[all])
Using cached faiss_cpu-1.12.0.tar.gz (69 kB)
Installing build dependencies ... done
Getting requirements to build wheel ... error
error: subprocess-exited-with-error

× Getting requirements to build wheel did not run successfully.
│ exit code: 1
╰─> [18 lines of output]
Traceback (most recent call last):
File "/home/user/.local/lib/python3.11/site-packages/pip/_vendor/pyproject_hooks/_in_process/_in_process.py", line 389, in <module>
main()
File "/home/user/.local/lib/python3.11/site-packages/pip/_vendor/pyproject_hooks/_in_process/_in_process.py", line 373, in main
json_out["return_val"] = hook(**hook_input["kwargs"])
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/user/.local/lib/python3.11/site-packages/pip/_vendor/pyproject_hooks/_in_process/_in_process.py", line 143, in get_requires_for_build_wheel
return hook(config_settings)
^^^^^^^^^^^^^^^^^^^^^
File "/tmp/pip-build-env-58c4ew4n/overlay/lib/python3.11/site-packages/setuptools/build_meta.py", line 331, in get_requires_for_build_wheel
return self._get_build_requires(config_settings, requirements=[])
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/tmp/pip-build-env-58c4ew4n/overlay/lib/python3.11/site-packages/setuptools/build_meta.py", line 301, in _get_build_requires
self.run_setup()
File "/tmp/pip-build-env-58c4ew4n/overlay/lib/python3.11/site-packages/setuptools/build_meta.py", line 317, in run_setup
exec(code, locals())
File "<string>", line 242, in <module>
KeyError: 'freebsd14'
[end of output]

note: This error originates from a subprocess, and is likely not a problem with pip.
ERROR: Failed to build 'faiss-cpu' when getting requirements to build wheel



 

[ralphbsz]

Start debugging the source files, file names are shown above. I suspect the problem is a mismatch between your OS and the package saying "freebsd14".

 

[Tracker]

Start debugging the source files, file names are shown above. I suspect the problem is a mismatch between your OS and the package saying "freebsd14".

Yea exactly - this happens way too often ..... is there no generic solution?

Else maybe I should just convert the dev environment part to a vm/ubuntu jail (not sure if that would work 100%) - what's the opinion there?