add tests for runtime config inside py-config and remove usage of indexURL

[madhur-tandon]

@hoodmane You might be able to chime in here.

The test loads the pyodide.js file which is present under node_modules/pyodide.
This further leads to loading of pyodide_py.tar and pyodide.asm.js

While /pyodide/pyodide.js and /pyodide/pyodide_py.tar are loaded correctly, the path for the last one is always wrong.
It is /build/pyodide/pyodide.asm.js instead of just /pyodide/pyodide.asm.js

What could be the reason for this? I also tried downloading the release from here: https://github.com/pyodide/pyodide/releases/tag/0.21.1

and using the downloaded folder as the path to indexURL (instead of the one from under node_modules/pyodide).

It seems like somewhere the path for where to look at pyodide.asm.js is set incorrectly. Can you confirm this?
Maybe it is related to the issue fixed here: pyodide/pyodide#3015?

[madhur-tandon]

TLDR:
The above issue is finally fixed.

Lessons learnt: Avoid using indexURL , let it be determined implicitly underneath

Issue:
Importing import { loadPyodide } from 'pyodide'; leads to weird behaviours where paths of files to be fetched such as pyodide.asm.js changes and it somehow uses /build/ prefix in the path which results in a 404. But if we don't import it, jest will be unhappy and won't let the unit tests for the runtime to pass as it won't be able to find loadPyodide since we didn't use the import explicitly.

Solution:

• Don't use import { loadPyodide } from 'pyodide'; at the top to avoid the wrong path behaviour.
• Use dynamic import in the unit test and make loadPyodide available to the global namespace, just for the sake of tests / making jest happy.
• Remove the usage of indexURL completely since it will always be determined automatically now, which is correct.
• Also, since indexURL is determined correctly now, the snippet to determine if we are inside jest is no longer needed and thus has been removed.

I have added comments to explain the JS voodo I did.

Consequence: All tests will pass and manually using py-config will also not fail now.

[antocuni]

Thank you @madhur-tandon: I suppose it was not an easy task to debug the indexURL issue, good job!

In general I'm very happy with this PR; I suggested a number of changes to make it even better. Don't be scared by the number of comments, most are shallow :).

I think this PR is missing a test, though. As I wrote in the comments, the current test_config is misnamed because it should be test_runtimes. But indeed, we do miss a test_config, i.e. the simplest possible test to check that <py-config> is loaded and evaluated by pyscript. Ideally, it should be placed before test_runtimes, because it tests a basic functionality which is a prerequisite for test_runtimes to work.

Looking at AppConfig, it seems we can also set the name and version of our app:

pyscript/pyscriptjs/src/runtime.ts

Lines 23 to 28 in 7be72ee

	export type AppConfig = {
	autoclose_loader: boolean;
	name?: string;
	version?: string;
	runtimes?: Array<RuntimeConfig>;
	};

So, a good way to write a test_config could be:

1. add some logging inside our typescript files to console.log appConfig_.name and .version if they are set (which looks generally useful)
2. write a minimal test which sets them via <py-config>
3. check that the correct name and version are printed to console.log

[madhur-tandon]

But indeed, we do miss a test_config, i.e. the simplest possible test to check that <py-config> is loaded and evaluated by pyscript.

Did you check the file pyscriptjs/tests/unit/pyconfig.test.ts @antocuni ?
I think that file serves the purpose doesn't it?

[fpliger]

Overall LGTM, left minor comments and, as @antocuni mentioned, can be addressed in a follow up PR

[antocuni]

veeeery nitpicking, but note that here you are loading 151MB in memory all at once, just to write them to disk. I'm sure there are better ways to save an http request to disk.
That said, it's not a blocker for this PR, but just wanted to say it as a general comment/suggestion for the future.

[madhur-tandon]

Chunking perhaps?

[antocuni]

chunking is surely a good option.
I would have expected requests to have a direct way to save to disk but apparently there isn't.
A quick google reveals this.