FFFF Upgrade to Pyodide 0.23 by JeffersGlass · Pull Request #1347 · pyscript/pyscript · GitHub
[go: up one dir, main page]

Skip to content

Upgrade to Pyodide 0.23 #1347

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

Merged
merged 24 commits into from
May 24, 2023
Merged
Changes from 1 commit
Commits
Show all changes
24 commits
Select commit Hold shift + click to select a range
ce31e38
Upgrade to Pyodide 0.23.0
JeffersGlass Apr 1, 2023
7bccf09
Update cached files listing
JeffersGlass Apr 1, 2023
2221e12
changelog
JeffersGlass Apr 1, 2023
291c6ff
Address hood's comments
JeffersGlass Apr 1, 2023
feba2eb
Address more comments
JeffersGlass Apr 2, 2023
87ca3cf
Update timeout lengths
JeffersGlass Apr 10, 2023
7682bed
Bump pyodide to 0.23.2
JeffersGlass May 10, 2023
b42cf5a
Merge branch 'main' into pyodide-0-23-0
JeffersGlass May 10, 2023
74edd00
Bump kmeans timeout time
JeffersGlass May 10, 2023
92e385c
Use @parma decorator to get brush param
JeffersGlass May 10, 2023
870cd06
Add a comment to force CI run
JeffersGlass May 11, 2023
6c136b3
Separate example tests to run sequentially
JeffersGlass May 12, 2023
c3befef
Remove extraneous example build
JeffersGlass May 12, 2023
335810d
Remove unnecessary 'make examples'
JeffersGlass May 15, 2023
e36a2b3
Merge branch 'main' into pyodide-0-23-0
JeffersGlass May 15, 2023
897af7b
Adjust makefile and rerun CI
JeffersGlass May 15, 2023
9197a3f
Remove pytest.raises from test, use check_js_errors
JeffersGlass May 15, 2023
413aefa
Add 'check_js_errors' to wait_for_pyscript
JeffersGlass May 15, 2023
0443dfc
Cleanup PR
JeffersGlass May 15, 2023
d91610c
Address some comments
JeffersGlass May 16, 2023
e7d5190
Adjust comment
JeffersGlass May 16, 2023
3e7114d
Rollback change to version check?
JeffersGlass May 16, 2023
c3ae4bd
Add comment on version
JeffersGlass May 21, 2023
f2d4b09
Merge branch 'main' into pyodide-0-23-0
JeffersGlass May 21, 2023
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
Bump kmeans timeout time
  • Loading branch information
JeffersGlass committed May 10, 2023
commit 74edd00d737dab154a6adc0e02ab0369bd96d559
2 changes: 1 addition & 1 deletion pyscriptjs/tests/integration/test_zz_examples.py
Original file line number Diff line number Diff line change
Expand Up @@ -278,7 +278,7 @@ def test_panel_deckgl(self):
def test_panel_kmeans(self):
# XXX improve this test>>>>>>> main
self.goto("examples/panel_kmeans.html")
self.wait_for_pyscript(timeout=90 * 1000)
self.wait_for_pyscript(timeout=120 * 1000)
Copy link
Contributor

Choose a reason for hiding this comment

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

Terrible. What kind of test requires a twelve second timeout? Scipy is the worst.

It'll be really nice once jspi is shipping in browsers and we don't have to preload scipy's 100+ .so files. In the meantime I think we should get rid of kmeans. If a single test doesn't test anything and requires a twelve second timeout it needs to be gotten rid of. If it does test something can anyone tell me what it tests and why it can't be done in a scipy free way?

8000

Copy link
Contributor

Choose a reason for hiding this comment

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

to be honest it feels like we test too much 3rd party in our integration when the goal should be "if 3rd party can be loaded, we're good" so I am actually curious myself why we take responsibility for all these foreign modules ... I understand the will to ensure stuff works, but having these as part of our testing pipeline seems a bit off to me.

Copy link
Contributor

Choose a reason for hiding this comment

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

to clarify further ... I think these tests should run only before a release and not for every commit we make to this project ... that would save time (both ours + computation) and grant we can tackle foreign modules gotchas before a release, not daily ... imho that would be great to me, so that code-freeze on release is meant to tackle possible gotchas and fix these if needed.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@hoodmane for what it's worth, that's a 120 second timeout 🤢

I'm more than happy to go an entirely different direction with testing and removing the examples from the testing workflow, or testing them only prior to release, or what have you. I was mostly looking for a straightforward path to get this lon 8000 g-standing PR merged and the project moved up to Pyodide 0.23/Python 3.11.

How would we feel about merging this as-is and following up with a separate PR/discussion about improving the examples testing process?

Copy link
Contributor

Choose a reason for hiding this comment

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

that would work for me

Copy link
Contributor

Choose a reason for hiding this comment

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

Rather than only before the release, I'd personally prefer to run them nightly or weekly or something like that. At least we are aware something broke sooner (and we don't have the overhead of testing examples before merging a PR)

In terms of testing too much 3rd party, I agree that we should test less and mainly focus on "if they load, we are good". There are some caveats though that I'd like for us to consider and add better support to specific 3rd party libraries. That's especially true for modules that are quite popular and don't just work with specifying them as dependencies. Take panel or bokeh as examples for instance, I'd like for us to make the user experience better and "auto-patch" everything they need to "just work" when you specify them as packages (but that is a totally different discussion and I think it probably belongs to PyScript core and rather to higher level API or something like this)

Copy link
Contributor

Choose a reason for hiding this comment

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

I'd personally prefer to run them nightly or weekly or something like that

that's a great idea too, as long as these are off our daily pipes around unrelated tasks

assert self.page.title() == "Pyscript/Panel KMeans Demo"
wait_for_render(
self.page, "*", "<div.*?class=['\"]bk-root['\"].*?>", timeout_seconds=60 * 2
Expand Down
0