Repository navigation
Import error due to missing symbol #2111
Description
Activity
@antonwolfy @ndgrigorian I have run into this issue as well. Any comment on this?
@icfaust, @david-cortes-intel The issue is because you have the latest dpctl installed with 2025.1 DPC++ RT package.
You need to update the env to install the latest 2025.2 components.The reason is that there is no "greater than" constraints for the DPC++ RT package in the METADATA:
$ cat ./pypi_venv/lib/python3.12/site-packages/dpctl-0.20.1.dist-info/METADATA | grep Requires-Dist Requires-Dist: numpy>=1.23.0 Requires-Dist: intel-sycl-rt Requires-Dist: intel-cmplr-lib-rt
but expected
intel-sycl-rt>=2025.2.Looks like the wheel is not taking the requirements from
requirements.txt:
https://github.com/IntelPython/dpctl/blob/master/requirements.txt.. and not taking them from
pyproject.tomleither:
https://github.com/IntelPython/dpctl/blob/master/pyproject.toml.. so I guess it would need to updated in some internal build script.
@david-cortes-intel, like mentioned in gh-1910, it's intended that they are not present in neither
requirements.txtnorpyproject.toml, assuming required packages might be provided by the user (like through installing oneAPI BaseKit).But it's different for the wheel packages on
https://software.repos.intel.com/python/pypichannel. The internal workflows extends dpctl'sMETADATAto add dependencies onintel-sycl-rtandintel-cmplr-lib-rt. I've filed a JIRA ticket to update the script with adding low and upper bounds for these dependencies (similar to ones which dpctl conda package has).@david-cortes-intel, like mentioned in gh-1910, it's intended that they are not present in neither
requirements.txtnorpyproject.toml, assuming required packages might be provided by the user (like through installing oneAPI BaseKit).But it's different for the wheel packages on
https://software.repos.intel.com/python/pypichannel. The internal workflows extends dpctl'sMETADATAto add dependencies onintel-sycl-rtandintel-cmplr-lib-rt. I've filed a JIRA ticket to update the script with adding low and upper bounds for these dependencies (similar to ones which dpctl conda package has).I see it mentions:
The dependencies list must specify Python only dependencies, assuming required libraries are provided by user's OS.
.. but the packages
intel-sycl-rtandintel-cmplr-lib-rtare distributed as PyPI packages even though they aren't python libraries, and those PyPI/conda packages are what other libraries using DPCTL would be loading at runtime.For the main installation flow you are right. If you are installing dpctl from the PyPI or conda-forge, then it's requires to have a correct dependency on
intel-sycl-rtandintel-cmplr-lib-rtfrom dpctl package.But alternatively, you might want to create a dev environment including DPC++ compiler (there is no wheel package for it) and dpctl installed to build dpnp from the source code. Or to test dpctl and dpnp with the latest nightly LLVM compiler.
For all that cases you would like to have more freedom how you would like to control the dependencies. And so, then you are building dpctl wheel from the source, or installing dev dpctl wheel package fromdppy/label/devchannel and so there will be no dependency on DPC++ RT assuming you are resolving them by yourself.For the main installation flow you are right. If you are installing dpctl from the PyPI or conda-forge, then it's requires to have a correct dependency on
intel-sycl-rtandintel-cmplr-lib-rtfrom dpctl package.But alternatively, you might want to create a dev environment including DPC++ compiler (there is no wheel package for it) and dpctl installed to build dpnp from the source code. Or to test dpctl and dpnp with the latest nightly LLVM compiler. For all that cases you would like to have more freedom how you would like to control the dependencies. And so, then you are building dpctl wheel from the source, or installing dev dpctl wheel package from
dppy/label/devchannel and so there will be no dependency on DPC++ RT assuming you are resolving them by yourself.But in that case, you'd either be building from an sdist, or through the setup.py file. Or are you also building a binary wheel for that use-case?
Or are you also building a binary wheel for that use-case?
Yes, if I need to install that dpctl into the dev dpnp environment.
Or are you also building a binary wheel for that use-case?
Yes, if I need to install that dpctl into the dev dpnp environment.
Then it sounds like building with system-managed vs. pip/conda-managed dpc++ runtime could be a configurable option.
As mentioned here we can add option dependency on the DPC++ RT package:
[project.optional-dependencies] coverage = [<SKIPPED>] docs = [<SKIPPED>] dpcpp_rt = ["intel-cmplr-lib-rt", "intel-sycl-rt"]As mentioned here we can add option dependency on the DPC++ RT package:
[project.optional-dependencies] coverage = [<SKIPPED>] docs = [<SKIPPED>] dpcpp_rt = ["intel-cmplr-lib-rt", "intel-sycl-rt"]I think (but not 100% sure) that still wouldn't work for the use-case of pip-installing requirements where those are transitive dependencies of other packages.
For example, other packages with DPC++ capabilities might specify them without version constraints, and if they are optional for the case of
dpctl, the pip resolver wouldn't take it into account and might still end up pulling incompatible versions.I'm a bit confused. If we are talking about default installation way. The DPC++ version constraints will be added to the dpctl wheel, we are working on that. There will be no optional dependencies added in scope of that.
If we are considering a use case when installing dpctl dev package, i.e. from either
dppy/label/devor built from the source, and the new optional dependency is added to the dpctl asdpcpp_rt(as proposed above).
In that case the newdpcpp_rtoptional dependency is not be transitive. If a package depends on dpctl and would like to ensure the proper DPC++ RT version installed, it would need to specifydpctl[dpcpp_rt]as a dependency.If you concerned about the above solution and missing the version constraints there. Then it was posted as an example, the implemented one will have the version constraints for sure, like:
[project.optional-dependencies] dpcpp_rt = ["intel-cmplr-lib-rt>=2025.2,<2026.0", "intel-sycl-rt>=2025.2,<2026.0"]
The DPC++ version constraints will be added to the dpctl wheel, we are working on that.
Thanks, that part wasn't clear to me.
But the snippet that you posted makes it an optional dependency. I think if you
pip installthat from arequirements.txtwhere other packages haveintel-sycl-rtas a mandatory dependency, it will end up ignoring the version constraints from that optional dependency.I checked that briefly and it seems that would work, the version constraints will be met.
In fact, in the future, I suggest avoiding using the internal logic for dependency correction. All dependencies should be listed in
setup.py, since the chain of calls is as follows:- run
pip install - read
pyproject.toml - check
[build-system], in dpctl/dpnp this issetuptools.build_metahttps://github.com/IntelPython/dpctl/blob/master/pyproject.toml#L2 pipcallssetuptools.build_metafor the build- if
setup.pyexists,setuptoolswill use it (pyproject.tomldefines backend and build deps, not run)
So my suggestion is to update
setup.py. The necessary dependencies should be listed there, and they will automatically appear in sectionRequires-DistinMETADATAfile after the build
Example:install_requires=[ "numpy", "intel-cmplr-lib-rt >=2025.3,<2026.0a0", "intel-sycl-rt >=2025.3,<2026.0a0" ],- run
In fact, in the future, I suggest avoiding using the internal logic for dependency correction. All dependencies should be listed in
setup.py, since the chain of calls is as follows:We chose not to do this because we want to support two separate use cases: one with Python packages in the environment and one with basekit, and don't want to install redundant packages.
CuPy, for example, is similar, noting that for the wheel to work correctly, the toolkit must be installed.
Reacted by Evseniia KomarovaIn fact, in the future, I suggest avoiding using the internal logic for dependency correction. All dependencies should be listed in
setup.py, since the chain of calls is as follows:We chose not to do this because we want to support two separate use cases: one with Python packages in the environment and one with basekit, and don't want to install redundant packages.
CuPy, for example, is similar, noting that for the wheel to work correctly, the toolkit must be installed.
Would also be helpful to offer an automated way of installing it with pip with necessary dependencies too, like
pip install dpctl[all]or similar. Otherwise, it's very confusing for someone not familiar with the intel ecosystem to have some packages liketorchworking one way (dependencies pulled withpip install) anddpctlworking another way (dependencies expected to be satisfied externally).Would also be helpful to offer an automated way of installing it with pip with necessary dependencies too, like
pip install dpctl[all]or similarI agree, I think that we should work out a preferred approach. Preferably, we can have both options (allowing basekit or automatic dependency resolution) when installing from PyPI, Intel channel, or conda-forge (in the future).
When installing the latest dpctl with pip, I get this error:
which demangles to:
I would guess that this is an issue of not specifying sufficiently high versions for all the sycl-related dependencies.
Rest of the environment is as follows:
Details