Make `rapidfuzz` optional on `sys_platform=emscripten`

[michaelweinold]

...until:

• https://github.com/brightway-lca/brightway-live/issues/59

is ready, this would fix:

• https://github.com/brightway-lca/brightway-live/issues/60
• https://github.com/brightway-lca/brightway-live/issues/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:

• https://github.com/brightway-lca/brightway2-data/commit/9e3e6138783113d12e9791b1be6baa81687d5096

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!