Fix issue detecting PyScript worker

[philippjfr]

This fixes an issue that @antocuni and @WebReflection heroically tracked down. Specifically the issue is that Panel makes various assumptions on which JS APIs it can use in a pyodide context based on whether js.document is defined. These assumptions do not hold when we are in a PyScript worker because there coincident is used to automatically proxy various JS APIs without having to rely on the custom JS <-> JS Worker message-passing implementation that Panel ships. The logic was incorrectly setting IN_WORKER=True when we were in a PyScript worker, which in turn causes Panel to make incorrect assumptions on how to pass messages and access DOM APIs.

Fixes #6995

[codecov]

Codecov Report

Attention: Patch coverage is 92.15686% with 4 lines in your changes missing coverage. Please review.

Project coverage is 81.76%. Comparing base (ec2e7b5) to head (9439e3a).
Report is 3 commits behind head on main.

Files	Patch %	Lines
panel/io/pyodide.py	0.00%	3 Missing ⚠️
panel/__version.py	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #6998      +/-   ##
==========================================
+ Coverage   81.25%   81.76%   +0.51%     
==========================================
  Files         326      326              
  Lines       48124    48164      +40     
==========================================
+ Hits        39104    39383     +279     
+ Misses       9020     8781     -239     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[WebReflection]

gotta be honest ... this line doesn't fully reason well to me ... if you are targeting very old version of PyScript Next you are patching your env the same ... by adding both js.document and js.window to your Worker global context.

Accordingly, if it works for the previous try attempt where you then set _IN_WORKER = False if no issues are found, why wouldn't that be the case also for ancient versions of PyScript next?

Or to rephrase ... why isn't the first try enough? If people are stuck in very old PyScript next they are also stuck in very old version of Pyodide thta might not necessarily bring in that very old version of panel neither ... do we need to support people stuck with outdated or deprecated PyScript versions there? Honest question though, maybe you had use cases before, I just think we should expect people being on 6 months old project or later at this point, and that js.document patch comes from very long time ago.

Thanks in advance for eventually expanding on that.

[philippjfr]

gotta be honest ... this line doesn't fully reason well to me ... if you are targeting very old version of PyScript Next you are patching your env the same ... by adding both js.document and js.window to your Worker global context.

Agreed, that was definitely not correct either.

If people are stuck in very old PyScript next they are also stuck in very old version of Pyodide thta might not necessarily bring in that very old version of panel neither

We strongly recommend people install Panel with the custom wheels we ship in our CDN (they are optimized for size), so the assumption that a particular old version of Pyodide will only load old versions of Panel doesn't necessarily hold.

I generally agree that we can reasonably expect people to be on more recent versions of Pyodide/PyScript but with the fixed logic I don't think there's any harm in keeping this.

[WebReflection]

with the fixed logic I don't think there's any harm in keeping this.

fair enough ... as long as you are testing/proving that logic still works ... which would surprise me, as the previous try fixes things in a different way and I expect that outer exception to produce broken logic you already fixed for the first try.

Those lines require more testing, more code, more everything, but it's your project, I am just saying "we encourage our users to always use our latest offer as the project is still relatively young and while robust/stable enough these days ... it's indeed in these days that we reached such stability" ... if that makes sense.

[philippjfr]

Part of the problem here was that recent changes to our build infrastructure caused all the PyScript tests to be skipped. I'm working on re-enabling the tests now and will have them error out if they can't be run.

[WebReflection]

All I am saying is that if you could just target latest PyScript and be sure stuff works we'll be all good, because we won't back-port fixes to previous releases and all we care about is that current stable channel remains stable.

That should be less work for your CI too ... and to be honest, we have people with problems from the 2yo PyScript version, those that jumped into Next already, are usually fine and well understands they might just update the version and have fixes all over the place out of the box.