docs: move to newest pyodide toolchain #2062
Conversation
Codecov Report
Additional details and impacted files |
|
@henryiii just assigning you to this so I don't lose track. |
agoose77
force-pushed
the
agoose77/docs-emsdk-version
branch
from
e773070 to
cc0e24f
Compare
agoose77
force-pushed
the
agoose77/docs-emsdk-version
branch
from
cc0e24f to
e3ebb79
Compare
|
@henryiii it looks like the pybind11 discovery is not succeeding in the venv that |
|
OK to use the git version post scikit-build/scikit-build-core#205 or should I push a patch release? |
|
For debugging sure! We would probably prefer a patch once it comes to releasing, but this isn't time critical. |
|
Yes, it would be nice to debug before release, so the release can contain fixes if needed. :) |
agoose77
force-pushed
the
agoose77/docs-emsdk-version
branch
from
9fcae19 to
be94ea8
Compare
|
With The contents of which includes pybind11, and the contents of So, it looks like the pybind11 files are in the places you described. I checked whether moving the |
|
@henryiii just a ping to see if you've had any more thoughts or tips on this! Let me know if you don't have availability, and I can try and push forward. |
|
@henryiii here's the full output from a local build: I can confirm that the site-packages directory does contain pybind11: $ ls /tmp/build-env-098k4w59/lib/python3.10/site-packages/pybind11 --tree
/tmp/build-env-098k4w59/lib/python3.10/site-packages/pybind11
├── __init__.py
├── __main__.py
├── __pycache__
│ ├── __init__.cpython-310.pyc
│ ├── __main__.cpython-310.pyc
│ ├── _version.cpython-310.pyc
│ ├── commands.cpython-310.pyc
│ └── setup_helpers.cpython-310.pyc
├── _version.py
├── commands.py
├── include
│ └── pybind11
│ ├── attr.h
│ ├── buffer_info.h
│ ├── cast.h
│ ├── chrono.h
│ ├── common.h
│ ├── complex.h
│ ├── detail
│ │ ├── class.h
│ │ ├── common.h
│ │ ├── descr.h
│ │ ├── init.h
│ │ ├── internals.h
│ │ ├── type_caster_base.h
│ │ └── typeid.h
│ ├── eigen
│ │ ├── matrix.h
│ │ └── tensor.h
│ ├── eigen.h
│ ├── embed.h
│ ├── eval.h
│ ├── functional.h
│ ├── gil.h
│ ├── iostream.h
│ ├── numpy.h
│ ├── operators.h
│ ├── options.h
│ ├── pybind11.h
│ ├── pytypes.h
│ ├── stl
│ │ └── filesystem.h
│ ├── stl.h
│ └── stl_bind.h
├── py.typed
├── setup_helpers.py
└── share
├── cmake
│ └── pybind11
│ ├── FindPythonLibsNew.cmake
│ ├── pybind11Common.cmake
│ ├── pybind11Config.cmake
│ ├── pybind11ConfigVersion.cmake
│ ├── pybind11NewTools.cmake
│ ├── pybind11Targets.cmake
│ └── pybind11Tools.cmake
└── pkgconfig
└── pybind11.pc |
|
Yes, I haven't figured out why it is having a problem yet. There's a toolchain file that sets |
|
Just saw this: pyodide/pyodide#3569 Not sure if it's related! |
|
This PR now builds, and pulls in the correct tooling. The built C++ wheel doesn't seem to load properly, though; the pybind11 module doesn't import. |
|
Can you try the native tooling? I think the problem is in pybind11 trying to "fix" the SO extension incorrectly. (Last two commits here: pybind/scikit_build_example#84) |
|
Broken due to emscripten-core/emscripten#19301. Hoping this can be patched somehow in pyodide. |
agoose77
added
the
pr-on-hold
Co-authored-by: Henry Schreiner <henry.fredrick.schreiner@cern.ch>
Co-authored-by: Henry Schreiner <henry.fredrick.schreiner@cern.ch>
agoose77
removed
the
pr-on-hold
Co-authored-by: Henry Schreiner <henry.fredrick.schreiner@cern.ch>
Co-authored-by: Henry Schreiner <henry.fredrick.schreiner@cern.ch>
Our existing CI requires several pieces of information to remain in sync in order to setup WASM building. With the new pyodide release, we can compute this (e.g. EMSDK version) at build time. This PR creates an additional
requirements-wasm.txtthat contains only thepyodide-builddependency meaning that all dependencies are contained in requirements files.This PR will fail whilst pyodide/pyodide#3415 is being fixed, modulo other bugs in the latest release.