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

[docs] add note about pyodide support #6715

Merged
merged 3 commits into from
Nov 15, 2024
Merged

[docs] add note about pyodide support #6715

merged 3 commits into from
Nov 15, 2024

Conversation

jameslamb
Copy link
Collaborator

This is SO COOL .... I learned tonight that Pyodide is building a version of the lightgbm Python package that runs in a web browser.

https://github.com/pyodide/pyodide/tree/main/packages/lightgbm

Try it yourself.... go to https://pyodide.org/en/stable/console.html (recommended from https://pyodide.org/en/stable/usage/index.html), and run the following:

import lightgbm as lgb
from sklearn.datasets import make_regression
from sklearn.metrics import r2_score

X, y = make_regression(n_samples=10_000, n_features=5, n_informative=5)
bst = lgb.train(
    train_set=lgb.Dataset(X, label=y),
    params={"objective": "regression", "verbose": -1}
)

print(r2_score(y, bst.predict(X)))
# 0.995701411473822
image

🤯 🤯 🤯 🤯

This proposes adding a note about that to the README.

Copy link
Collaborator

@StrikerRUS StrikerRUS left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! Interesting project indeed! I have never heard about it before.

README.md Outdated Show resolved Hide resolved
jameslamb and others added 2 commits November 11, 2024 17:07
Co-authored-by: Nikita Titov <nekit94-08@mail.ru>
@StrikerRUS StrikerRUS merged commit 83c0ff3 into master Nov 15, 2024
49 checks passed
@StrikerRUS StrikerRUS deleted the docs/pyodide branch November 15, 2024 12:30
@agriyakhetarpal
Copy link

Thanks for the note! Would y'all consider helping us where you can by adding a few representatives/core developers/maintainers as maintainers for LightGBM's recipe?

This way, users would know who to ping in case they face issues with running LightGBM in Pyodide, and we can reach out when we face troubles with updating its version. In case there are concerns about the time required to spend on this – neither of these things should be a frequent occurrence; we usually update versions periodically when we are close to a new release or when we bump the Emscripten version and break the ABI (around twice a year).

@agriyakhetarpal
Copy link

FYI, I also noted #5372 – which is a topic that Pyodide resolves by providing LightGBM to run in WASM environments. An out-of-tree CI job for Pyodide as a target could prove to be useful, see: https://pyodide.org/en/latest/development/building-and-testing-packages.html

@jameslamb
Copy link
Collaborator Author

Would y'all consider helping us where you can by adding a few representatives/core developers/maintainers as maintainers for LightGBM's recipe?

You can add my GitHub handle as a start, I will try to help when I can. Will leave it to other maintainers here to tell you if they'd like to be added.

FYI, I also noted #5372 – which is a topic that Pyodide resolves by providing LightGBM to run in WASM environments.

Please comment on that issue with links to any relevant examples that someone finding it from search (or subscribed to notifications) could use to understand how to use pyodide to run LightGBM in WASM. Then we can close that on the feature tracker.

An out-of-tree CI job for Pyodide as a target could prove to be useful, see: https://pyodide.org/en/latest/development/building-and-testing-packages.html

Thanks for that link. This is the first time I've heard the phrase "out of tree", and to be honest I don't totally understand what you mean.

Are you asking us to start building WASM wheels and uploading them to https://pypi.org/project/lightgbm/? If so... what's the benefit of doing that when pyodide is already maintaining lightgbm builds at https://github.com/pyodide/pyodide/blob/0ece5258aea9ee6848e7128b59abd759c20a88b8/packages/lightgbm/meta.yaml?

@agriyakhetarpal
Copy link

You can add my GitHub handle as a start, I will try to help when I can. Will leave it to other maintainers here to tell you if they'd like to be added.

Please comment on that issue with links to any relevant examples that someone finding it from search (or subscribed to notifications) could use to understand how to use pyodide to run LightGBM in WASM. Then we can close that on the feature tracker.

Thank you for volunteering, @jameslamb – I'll do both of those things!

An out-of-tree CI job for Pyodide as a target could prove to be useful, see: pyodide.org/en/latest/development/building-and-testing-packages.html

Thanks for that link. This is the first time I've heard the phrase "out of tree", and to be honest I don't totally understand what you mean.

Are you asking us to start building WASM wheels and uploading them to pypi.org/project/lightgbm? If so... what's the benefit of doing that when pyodide is already maintaining lightgbm builds at pyodide/pyodide@0ece525/packages/lightgbm/meta.yaml?

No, PyPI does not support uploads WASM wheels yet, unfortunately. That would require a PEP, which I don't think we will be able to find a sponsor for in near time. We currently host WASM wheels for all the packages we are able to build for on our own with an interface via the JSDelivr CDN, thereby providing an entire "distribution" of CPython for WASM rather than just an "implementation".

To answer your question more specifically: yes, we do maintain lightgbm builds at the link you've mentioned, but those are tied to a specific version of lightgbm, which gets updated manually from time to time (as noted in #6715 (comment)) and we need to fix any failing tests or deal with changes in public APIs. An "out of tree" (outside the Pyodide repository) CI job in the LightGBM repository means that WASM wheels will be built and tested with PRs and on every commit to the main branch, similar to CI jobs for conventional platform targets like Unix/Windows – so that changes that break functionality within a WASM environment are caught and can be potentially addressed as development proceeds. Effectively, that would mean less maintenance for us when we try to update LightGBM's version in-tree (within the Pyodide repository) going forward. :) Also, WebAssembly has 32-bit indexes by default right now, and I see that LightGBM has 32-bit builds already, so my hunch is it shouldn't be too painful to debug issues/failures down the line once a job is set up. There is a chance we might be able to provide a more public and accessible location for hosting wheels on the internet for downstream users (please see pyodide/pyodide#3049) where these WASM wheels can then be uploaded to at a later date.

@jameslamb
Copy link
Collaborator Author

Ah great, thanks for that explanation! I'm willing to try this at some point, and we can see how much maintenance effort it is to set up and maintain.

Let's use #5372 to track that work.

I think it won't be a high near-term priority for us, but something I'd like to eventually try adding. Until then, you can @ me any time in the pyodide repo if LightGBM is causing any issues.

WebAssembly has 32-bit indexes by default right now, and I see that LightGBM has 32-bit builds already

Thanks for explicitly calling this out, it might have taken a while for me to discover! We do support a 32-bit build, but only on Windows:

LightGBM/build-python.sh

Lines 138 to 142 in 6e0b0a8

--bit32)
export CMAKE_GENERATOR="Visual Studio 17 2022"
export CMAKE_GENERATOR_PLATFORM="Win32"
echo "[INFO] Attempting to build 32-bit version of LightGBM, which is only supported on Windows with generator '${CMAKE_GENERATOR}'."
;;

But don't test that configuration in CI.

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

Successfully merging this pull request may close these issues.

3 participants