False warnings that Pyodide 0.29.1 might not support `pillow` and `beartype`

[jolaf]

Both pillow and beartype work perfectly, but the warnings are still emitted, as of PyScript 2026.1.1:

As far as I understand, the warnings are emitted here:
https://github.com/pyscript/polyscript/blob/main/esm/interpreter/pyodide.js#L90
and the data defining if the warning would be emitted or not, are located here:
https://github.com/pyscript/polyscript/blob/main/esm/interpreter/pyodide_graph.js
As far as I can see, Pillow is mentioned, but emitted warning mentions pillow.
I'm not sure which lettering is correct, but the warning seems to be caused by this discrepancy.

As of beartype, it's not mentioned, but it definitely works under PyScript and is very useful.
I don't know what are the criterie for whitelisting a package, but from my point of view beartype doesn't deserve a "might not support" warning.

[jolaf]

If I replace pillow with Pillow in my pyscript.toml, warning disappears.

However, the app works fine with both old and new configurations, so it seems that both settings are recognizable and probably lead to the same library. However, only one of them is whitelisted.

Probably whitelist should be case insensitive, as well as checks against it?

[WebReflection]

@jolaf not the first time you pay a bit too much attention to warnings, which are not errors, just warnings but in this case we just grab details (once per release) from https://pyodide.org/en/stable/usage/packages-in-pyodide.html where it's Pillow indeed, not pillow, while beartype is nowhere in that list, hence the warning.

That being said:

Probably whitelist should be case insensitive, as well as checks against it?

I don't know ... @ntoll, what do you think? does it make any difference if we lowercase all the packages? If not, I'd be keen to fix this but unknown packages will still show that warning because we cannot know, until you download and use those, if these are supported, and it was asked by the community to provide feedback on packages, mostly because this way we can usually catch typos right away, but we cannot know AOT if that's really a typo or a weird name for a package.

[jolaf]

you pay a bit too much attention to warnings, which are not errors, just warnings

Sorry, they make me uncomfortable. :(

You definitely may safely ignore my issues or assign them the lowest priority if you think they're irrelevant for now. If I see a problem, I think I should report it, and I try do to so when I can. Afterwise it's of course the team's discretion whether to do anything about it.

unknown packages will still show that warning

That sounds absolutely reasonable to me.

this way we can usually catch typos

And this too.

I was confused mostly because everything worked for me. If pillow was just a typo, Python would not let me import PIL and would throw an exception. But everything worked, so I was sure that no typo is involved.

So maybe whitelist could be left as is, but instead the question would be: "Why pillow worked despite the typo?"
If it didn't, I would surely think about potential typo and find it.

we just grab details (once per release) from https://pyodide.org/en/stable/usage/packages-in-pyodide.html

Oh, thanks for pointing this out!
Maybe that link could accompany the warning, like the one about SharedBuffer?
It would allow a user to immediately understand, why the warning and whether they should do anything about it.

[jolaf]

It's also interesting, that, for example, coolname is not mentioned in https://pyodide.org/en/stable/usage/packages-in-pyodide.html, and still no warning is emitted about it.

Moreover, I've just introduced a typo:
packages = ["coolnameZ", "beartype"]
and here's what happened:

Package failed to download, and yet there was no warning.

[WebReflection]

MR landed

If I see a problem, I think I should report it, and I try do to so when I can

of course, appreciated 🙏

mine wasn't a critique, rather the fact we have warnings for reasons and nobody using out there PyScript will notice those but developers can have better feedback, which is the reason we add warnings: our users asked for those!

"Why pillow worked despite the typo?"

every package that is not in that list will show a warning ... the warning doesn't state "watch out, this won't work", it clearly states "this package MIGHT not work" so the surprise shouldn't be a surprise, in that regard, as pure Python wheels will likely always work in Pyodide but those using stuff that cannot work on the Web? who knows, hence the warning and the might in it.

Maybe that link could accompany the warning, like the one about SharedBuffer?

yes and no, there could be well known modules we know for sure work today and will work tomorrow so that linking to a page that shows those modules are not, in fact, part of the list feels like little value to me, happy to change my mind but even the SAB link didn't bring nearly as much help as we hoped, people don't usually read errors, even less click on links within errors 😅

Curious to know what @ntoll thinks about this, yet the MR is ready and it looks sensible to me to land that as it is: both Pillow and pillow as package will result into pillow entry in the graph, just like that.

[ntoll]

@jolaf you're on fire 🔥 - and like you I get annoyed by warnings and such things (especially in test suites). I hear ya!

Looking at how PyPI resolves packages - they're treated as case insensitive by the website (e.g. arrr, Arrr, aRrr are all the same package). So lower-casing all the things feels like the correct solution to me. 👍

[jolaf]

I fully agree that warnings are useful, these particular warnings too!

there could be well known modules we know for sure work today and will work tomorrow

Well, if they don't cause the warning, the user would not get the link. :)

people don't usually read errors, even less click on links within errors

I feel your pain. :(

[WebReflection]

Well, if they don't cause the warning, the user would not get the link. :)

what I mean, pointing at a page where that package doesn't exist doesn't feel like the best approach to me ... once you are there, what else could you do? double check that indeed the package is not there? what's next from there?

I'd rather improve by pointing at PyPI search page or even our own search page than pointing people to a Pyodide page we already know won't contain that specific package, so I am with you, warnings should be more helpful, here I think a link to the page that contains zero details about beartype, as example, won't really help anyone out there ... I hope I've explained myself better.

[jolaf]

once you are there, what else could you do? double check that indeed the package is not there? what's next from there?

My idea was I may find that the package in question IS there, and that would lead me to check my config for typos.

Link to the page with the link and also some explanation is even better, of course.

[WebReflection]

so ... to close the circle, how about we link to https://pyscript.github.io/pyscript-packages/package/?package=beartype instead, if a package shows warnings? In there you can provide feedback, read details, you have links to PyPI, a test editor ... wouldn't that be a better feedback for all of us? 🤔

[WebReflection]

as follow up for @ntoll too, maybe we can also improve this page to point at Pyodide page, something like:

are you sure you spelled the name correctly? here packages available for stable Pyodide, here PyPI search itself to refine

something that helps more than this? https://pyscript.github.io/pyscript-packages/package/?package=unknown_package_nope