-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Emscripten wheel fixes and test coverage #2739
Conversation
7c68aa5
to
a7d22de
Compare
return rustWheelsDir; | ||
} | ||
export function getEmscriptenWheelPath() { | ||
const pspVersion = getWorkspacePackageJson().version; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure, is the workspace package.json an OK place to get the version of the emscripten wheel? Or should this read from rust/perspective-python/Cargo.toml? If they're meant to be kept in sync, it shouldn't matter, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
repack_wheel uses the version from pacakge.json to construct the version number for the .data directory, so seems reasonable to use it here too
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
huh, interesting. maybe should do like perspective-python's JS build script, and read it from perspective-python's package.json
https://github.com/finos/perspective/blob/master/rust/perspective-python/build.mjs#L28-L30
edit: fixed link
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We update all package.json
files at once, so the "local" one is the right place to fethc it generally, except the scripts in perspective-scripts
don't live in a module, so the workspace package.json
is the only option.
} | ||
export function getEmscriptenWheelPath() { | ||
const pspVersion = getWorkspacePackageJson().version; | ||
const wheeljunk = "cp39-abi3-emscripten_3_1_58_wasm32"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not sure if there's a good way to compute this (from the pyproject.toml? or Cargo.toml?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it's probably OK to leave it like this, and just adjust it whenever it breaks; when we change ABIs or emscripten versions or whatever
Actually, on second thought, we could compute the emscripten version at least, since that's in pacakge.json
. Although that may be short lived; newer pyodide-build wheels don't have the emscripten version in them, instead it's like pyodide_2024_0_wasm32
; it's unclear to me if they'll be dropping support for wheels named with the emscripten version in them, but they do work currently w/ 0.26.2
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMO we get this by listing any .whl
target with "emscripten" in the triple name - and if there are two (or more), error with a message instructing the dev to run pnpm run clean
.
} | ||
} | ||
|
||
downloadPyodide(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
was looking for an equivalent to if __name__ == "__main__"
but the closest I could find appears to be undergoing active bikeshedding nodejs/node#49440
require.main
doesn't work in Node esm
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's no easy way to do this, but every script in this folder should be considered a "main" script, that's what the folder is for. There are a handful of exceptions already e.g. sh.mjs
.
e28b2c9
to
1497a50
Compare
Switch from using CMAKE_CXX_FLAGS, which has confusing and global semantics, to calling target_compile_options on all the targets This confines all the pyodide exception build code to a single branch of the cmake file Remove some commented-out code and dead branches in the build. I think this helps with reading and scanning the Cmake files Signed-off-by: Tom Jakubowski <tom@prospective.dev>
This fixes a nasty warning on installing the wheel. It could likely be fixed another way, maybe with linker flags, but we decided to cut the feature since it's not of main importance Signed-off-by: Tom Jakubowski <tom@prospective.dev>
Signed-off-by: Tom Jakubowski <tom@prospective.dev>
Signed-off-by: Tom Jakubowski <tom@prospective.dev>
This makes our wheel compatible with widgetsnbextension 4.0.11, which is the version provided by jupyterlite-pyodide-kernel 0.4.1 Signed-off-by: Tom Jakubowski <tom@prospective.dev>
In setup, this package selects `perspective-python` and sets some environment variables to make the build run for Pyodide. Co-authored-by: Andrew Stein <steinlink@gmail.com> Signed-off-by: Tom Jakubowski <tom@prospective.dev>
Integration/smoke tests for the Pyodide wheel, which run for the perspective-pyodide virtual package and in the Pyodide CI actions. Some changes which support installing the wheels in a pytest-pyodide environment: - Defer some third-party imports to "run time" by moving them deeper than module scope - Add try/except guards to widget re-exports so that wheel can be used without Jupyter being installed - Move Jupyter deps in pyproject.toml to an optional-dependencies group Signed-off-by: Tom Jakubowski <tom@prospective.dev>
This makes the emscripten wheel build on normal PRs Signed-off-by: Tom Jakubowski <tom@prospective.dev>
This `import assert` syntax is experimental, and was removed in newer Node versions in favor of with `import ... with`. some node versions (including Node 18) support both syntaxes Unsure what minimum node version we need to support - if we can restrict to Node 18+, then we could instead replace this with `import ... with` Signed-off-by: Tom Jakubowski <tom@prospective.dev>
Signed-off-by: Tom Jakubowski <tom@prospective.dev>
1497a50
to
25158fd
Compare
(Remove accidentally included debug log) Signed-off-by: Tom Jakubowski <tom@prospective.dev>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the PR! Looks good!
This is a lot of commits for a cleanup PR but I will let it slide this time because the commits are descriptive and additive! (e.g. no "WIP reverting previous commit" or the like).
}, | ||
"devDependencies": { | ||
"@finos/perspective-scripts": "workspace:*", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Posthumous review update -
Packages in the tools/
directory are private to the source repository and they can't be included as dependencies in the published packages, even if they are just dev dependencies, because these tools ultimate are intended to depend on Perspective also and you end up with circular imports.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense. I didn't know that we don't publish @finos/perspective-scripts
to NPM
pnpm run setup
, which builds perspective-python with Pyodide environment flags set#
and//
flavorsimport
asserts for readingpackage.json
with new helpers, which improves forwards Node compatibility