Set pybind11 to ValeevGroup/v2.11

[evaleev]

for some reason py3.12 is picked up again in https://github.com/evaleev/libint/actions/runs/6987480217/job/19014069994?pr=283#step:14:153 .. I thought https://github.com/evaleev/libint/pull/280 addressed this by pinning to 3.11 MacOS CI jobs ..

[asadchev]

I think easiest is for me to fix it. Is there MAC i can use?

On Sun, Nov 26, 2023, 4:18 PM Eduard Valeyev @.***> wrote:

for some reason py3.12 is picked up again in https://github.com/evaleev/libint/actions/runs/6987480217/job/19014069994?pr=283#step:14:153 .. I thought #280 https://github.com/evaleev/libint/pull/280 addressed this by pinning to 3.11 MacOS CI jobs ..

— Reply to this email directly, view it on GitHub https://github.com/evaleev/libint/pull/283#issuecomment-1826899630, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABH62KGUA2B7HD3MXJMRHM3YGOWZ7AVCNFSM6AAAAAA7YNXLKSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMRWHA4TSNRTGA . You are receiving this because you authored the thread.Message ID: @.***>

[evaleev]

I think easiest is for me to fix it. Is there MAC i can use? …

I think this is not related to MacOS, but due to the use of py3.12 ... try running pylibint tests built w/ py3.12 on Linux

[evaleev]

I see master has macOS python tests disabled per #280, you reenabled them in https://github.com/evaleev/libint/pull/283/commits/77c26cc8f003e418cf6cef83c5d395324e89f624 ... the issue is pylibint w/ py3.12 does not seem to work (recall the GIL check failure)

[loriab]

Is it the intent that only the ValeevGroup fork of pb11 (and never a generic upstream release) is suitable for pylibint? If so, perhaps find_package(pybind11 2.6.0 CONFIG) should be commented out.

[evaleev]

Is it the intent that only the ValeevGroup fork of pb11 (and never a generic upstream release) is suitable for pylibint? If so, perhaps find_package(pybind11 2.6.0 CONFIG) should be commented out.

there is only 1 extra file we need on top of stock pb11 (https://github.com/pybind/pybind11/commit/42b42ce0071413ba63fbc056f0316a85adbfefc4), for handling boost::container::small_vector ... unfortunately we can'd PR upstream since it's too specialized. We need this across the board (e.g. in https://github.com/ValeevGroup/tiledarray). Unfortunately there is no good way to reuse a single file across multiple packages without creating the extra boilerplate to maintain. We are considering submodules. We manually prepare releases, so the inability of GitHub to package submodules source into releases (https://github.com/dear-github/dear-github/issues/214) does not affect libint.

Comments are welcome.

[asadchev]

Re Python 3.12 It's only been two months since 3.12 release and there are changes re GIL. Pybind11 probably hasn't caught up with all bugs that may exist. We shouldnt try to support 3.12. Python interpreter can be set explicitly via CMake to be not 3.12

On Mon, Nov 27, 2023, 10:56 AM Eduard Valeyev @.***> wrote:

Is it the intent that only the ValeevGroup fork of pb11 (and never a generic upstream release) is suitable for pylibint? If so, perhaps find_package(pybind11 2.6.0 CONFIG) should be commented out.

there is only 1 extra file we need on top of stock pb11 (pybind/pybind11@ 42b42ce https://github.com/pybind/pybind11/commit/42b42ce0071413ba63fbc056f0316a85adbfefc4), for handling boost::container::small_vector ... unfortunately we can'd PR upstream since it's too specialized. We need this across the board (e.g. in https://github.com/ValeevGroup/tiledarray). Unfortunately there is no good way to reuse a single file across multiple packages without creating the extra boilerplate to maintain. We are considering submodules. We manually prepare releases, so the inability of GitHub to package submodules source into releases (dear-github/dear-github#214 https://github.com/dear-github/dear-github/issues/214) does not affect libint.

Comments are welcome.

— Reply to this email directly, view it on GitHub https://github.com/evaleev/libint/pull/283#issuecomment-1828118966, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABH62KDGFOZY4RBFOFBOD53YGSZ4LAVCNFSM6AAAAAA7YNXLKSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMRYGEYTQOJWGY . You are receiving this because you authored the thread.Message ID: @.***>

[loriab]

Is it the intent that only the ValeevGroup fork of pb11 (and never a generic upstream release) is suitable for pylibint? If so, perhaps find_package(pybind11 2.6.0 CONFIG) should be commented out.

there is only 1 extra file we need on top of stock pb11 (https://github.com/pybind/pybind11/commit/42b42ce0071413ba63fbc056f0316a85adbfefc4), for handling boost::container::small_vector ... unfortunately we can'd PR upstream since it's too specialized. We need this across the board (e.g. in https://github.com/ValeevGroup/tiledarray). Unfortunately there is no good way to reuse a single file across multiple packages without creating the extra boilerplate to maintain. We are considering submodules. We manually prepare releases, so the inability of GitHub to package submodules source into releases (https://github.com/dear-github/dear-github/issues/214) does not affect libint.

Comments are welcome.

Ok, thanks for the clarification. The forked source doesn't bother me at all, since psi4/c-f don't use/package pylibint; I mostly deal with pylibint in CI. I just wanted to make sure the find_package(pybind11) line (added in #268) wasn't going to interfere with your intent.

[evaleev]

@asadchev btw, relevant: looks like pybind11 can use targets provided by FindPython if it's loaded before pybynd11: https://pybind11.readthedocs.io/en/stable/cmake/index.html#new-findpython-mode