Update repository for conan2 #365
Conversation
… instead of default python2
|
Might this be a good point to also try to get rid of the custom cmake code in setup.py and try if we can use |
| if self.options.with_python: | ||
| self.requires("pybind11/2.10.1") | ||
| if self.options.with_testing: | ||
| self.requires("boost/1.78.0") | ||
| self.requires("boost/1.75.0") |
There was a problem hiding this comment.
why the downgrading from 1.78 to 1.75
There was a problem hiding this comment.
cubicinterpolation itself has a requirement of 1.75.0, and somehow this creates a conflict in conan when proposal defined a different version.
However, this is only relevant if one wants to build the tests. It shouldn't make any practical difference.
Since we are touching the |
| from conan.tools.microsoft import is_msvc | ||
| from conan.tools.scm import Version | ||
|
|
||
| required_conan_version = ">=1.53.0" |
There was a problem hiding this comment.
Just to be sure: this conanfile is still compatible with conan 1?
There was a problem hiding this comment.
Yes. At the moment, the conanfile is written in such a way that it is backwards-compatible with conan 1.x.
I never worked with compiled parts of a python package, but I wonder how |
|
Maybe also open an issue about a possible conan integration in the new scikit-build-core project? They are rewriting from scratch and handling the C++ dependency is probably important for more people: |
Maybe it's better if you open an issue, since I have no idea about scikit-build and C++ distribution through pip and only used conan in one project :D |
Co-authored-by: Ludwig Neste <[email protected]>
|
How to we want to proceed with the |
I would do so, unless you we want this to be a pilot-project for a custom conan+scikit-build workflow... |
|
How to we want to go forward with this MR? This is the last issue I would like to solve for the next release. Does this concept work for you? |
This PR updates the conanfile, the installation instructions, setup.py, and the github actions scripts to be compatible with conan2.
The old installation approach, which relied on the
cmake_pathsgenerator of conan, has been deprecated.Instead, I have oriented myself on the procedure presented in the conan2 tutorial, which uses the approach where conan creates a CMake toolchain file which tells CMake where to find the packages installed by conan. This has the advantage that the conan installation process is completely separated from the rest of our CMake structure.
The installation procedure using conan and CMake now has a few more steps, but is more transparent for the user.
pip install proposalstill works ous of the box. With the update to conan2, a lot of issues that required manual intervention by us (for example thelibcxxsettings) have been resolved, which also simplified thesetup.py.The description of the installation process as well as the
setup.pyare not backwards-compatible with conan 1.x.Therefore I gave
pip install "conan~=2.0"as an explicit instruction in the INSTALL.md for now.Other changes