Skip to content
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

Add rapidfuzz #1272

Draft
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

michaelweinold
Copy link
Contributor

No description provided.

@michaelweinold
Copy link
Contributor Author

@DerThorsten, thank you for adding your fixes to the build recipe - I can see the PR build is now stuck on a build_with_rattler function. Is this a known problem?

@DerThorsten
Copy link
Contributor

@michaelweinold the problem is, it drags in a outdated build of the emscripten compiler

emscripten_emscripten-wasm32 ┆ 3.1.45 ┆ h7b187fe_15 ┆ emscripten-forge ┆ 7.19 KiB │
the problem is the build number, it is at 15, we need build 29.
Normally this is picked up without any problems, but some package constraints drag in this old build.
I probably need to remove the old builds of the compiler by hand :/

@DerThorsten
Copy link
Contributor

@michaelweinold the old unusable builds of the compiler will be remove at some point in the nearby future (cannot give you a specific time as I cannot do this by myself)

@DerThorsten
Copy link
Contributor

@michaelweinold So now it uses the proper emscripten compiler, but fails with some different stuff

@michaelweinold
Copy link
Contributor Author

"At least" the error message is similar to those of other failing (auto-)builds, like:

@maxbachmann
Copy link

@michaelweinold I am the author of the rapidfuzz package. First a couple of notes:

  • I did improve the build of rapidfuzz to include -fexceptions so it doesn't crash when rapidfuzz uses C++ exceptions in emscripten.
  • The package does now use scikit-build-core. This mentions supporting emscripten while scikit-build doesn't.
  • In my CI I can now successfully build + test the package using cibuildwheel
  • I am not completely sure whether numpy should be a runtime dependency. In the python package it's an optional dependency since it's only required by a small subset of the library. Given the size I assume it could make sense not to include it here and let the users install it themselves if needed for their application.

Where is the standard place to add emscripten/pyodide packages? I noticed there is both emscripten-forge and pyodide. Would a package usually get added to both of them?

@michaelweinold
Copy link
Contributor Author

Hello @maxbachmann! Thank you for getting in touch.
Pyodide is a monolithic distribution - any packages added there will be shipped with Pyodide itself. Emscripten Forge (if I understand correctly) works like the Conda Forge package repository, which allows you to install packages as needed.
I will try to find time to re-do the build here based on the latest version of rapidfuzz early next year.

psychemedia added a commit to f1datajunkie/jupyterlite-fastf1 that referenced this pull request Jan 13, 2025
@psychemedia
Copy link

I'm trying to make use of rapidfuzz in a JupyterLite xeus-python environment, which installs wasm32 build packages from emscripten-forge, so I'd +1 on this being added as a feedstock. :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants