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

Forever hanging mip should correctly handle .mpy and .py files as binary content. #100

Open
ntoll opened this issue May 18, 2024 · 2 comments

Comments

@ntoll
Copy link
Member

ntoll commented May 18, 2024

Context here: pyscript/pyscript#2063

@JeffersGlass
Copy link
Member

@WebReflection responding here to the ping you sent me on Discord for visibility - it seems there have been updates to mip as you can see here. The most relevant change, i think, is quite a bit of additional detail and work around _download_file(), which has some additional error handling... but our (older) version also writes files in binary (wb) mode, so I'm not positive that's the culprit.

In any case, it would probably be good to update our version of Mip to reflect some of those new changes.

@WebReflection
Copy link
Contributor

Hi @JeffersGlass I did talk to @dpgeorge and there's more to it ... we're using synchronous XHR which can't provide arrayBuffer as response due browsers limitations around its synchronous nature (when specified) but once we make the XHR async we're better off with fetch instead, as that's not deprecated.

In pyodide the dance to install packages is already async so I think a whole rewrite would be for good but Damien mentioned that maybe the mip.py logic should be provided by MicroPython itself, which is closer to upstream changes around mip in general, and we can just pre-parse / amend our own github: prefix dance when any package uses that convention ... thoughts?

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

No branches or pull requests

3 participants