- Sponsor
-
Notifications
You must be signed in to change notification settings - Fork 276
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
generate-ci'd emscripten pytest fails before reaching module code #2071
Comments
Workaround-For: PyO3/maturin#2071
Workaround-For: PyO3/maturin#2071
I don't know either, @hoodmane any idea? |
cc @ryanking13. I'm not sure why it's trying to run those tests but I think they were meant to run in the emscripten source tree and weren't meant to run on install. I wonder why they are running here. |
It looks like emscripten is installed under So I guess you need to
|
Just to not drop the ball, is that something I can act on in my repository (doesn't seem like it, it doesn't touch emsdk installation), something where we'd need to change the generate output, or something where we'd need to pull in maintainers of the action repositories supplying the CI steps? |
Well, I think the easiest way, and what I would like to recommend, is specifying the files/directory to test by pytest clearly. By adding |
Bug Description
In cbor-diag-py, which is an almost trivial1 project following the maturing scaffolding of
maturin new
andgenerate-ci
, the emscripten tests fail, seemingly before they even touch code.Excerpt of the latest CI run
Given that nothing in the errors appear to be related to the cbor-diag module, it appears that this is an issue with maturin or the actions added in generate-ci. I'm a bit lost at why the emscripten tests are even called, do you have any pointers to track this down further?
Your maturin version (
maturin --version
)1.5.1
Your Python version (
python -V
)3.11.8
Your pip version (
pip -V
)24.0
What bindings you're using
pyo3
Does
cargo build
work?If on windows, have you checked that you aren't accidentally using unix path (those with the forward slash
/
)?Steps to Reproduce
The issue is with what happens on GitHub actions, I don't think this can be reproduced locally.
Footnotes
The package uses altered paths and a manual init to avoid the public modulename.modulename API guarantee tracked in Defining a module
foo
results infoo.foo
being available #1399 ↩The text was updated successfully, but these errors were encountered: