Make rapidfuzz optional on sys_platform=emscripten

[michaelweinold]

...until:

• Add rapidfuzz to emscipten-forge and Pyodide brightway-live#59

is ready, this would fix:

• Create Platform-Specific Dependencies in Brightway Packages brightway-live#60
• bw2io, bw2data, bw2calc, WASM Compatibility Issues (2024) brightway-live#57

[michaelweinold]

...hmmm, that is annoying. I just added the same condition to my testing package - and the build ran fine there.

[michaelweinold]

...must have been the semicolon.

[michaelweinold]

@cmutel, not sure what black magic I need to re-run the checks on this PR. Otherwise ready for review.

[cmutel]

I think the review comes before CI, though I don't really understand that... Don't we also need to shortcircuit the calls which use rapidfuzz, or am I missing other commits or PRs? It seems like this would just lead to an import error.

[michaelweinold]

Since you answer to my question

Is there already a fallback such that whatever-was-used-before-rapidfuzz is used instead, when rapidfuzz is not available?

Was "Yup", I assumed all those short-circuits would be in place. Maybe I should have had a look at the link you provided...

[cmutel]

OK, CI isn't running because the code didn't change, only the build config.

[michaelweinold]

Commit that introduced rapidfuzz and DamerauLevenshtein.distance:

• 9e3e613

Since the string_distance.py file is still present, we could simply have bw2data fall back to it if rapidfuzz is not installed?

[cmutel]

Since the string_distance.py file is still present, we could simply have bw2data fall back to it if rapidfuzz is not installed?

Sure, that would work; the API might be slightly different but we can control it in the file we included (i.e. make it fit rapidfuzz).

[michaelweinold]

...ok, I think it's all ready - you're already falling back to the string_distance.py file anyway!