interesting, here my counter-arguments:

• why does it need to be a browser_environment.json thing? wouldn't an env.json fulfill the same purpose, as long as it has a browser field in it?
• you are assuming we know dependencies paths ... well, we don't, we let micropip do its job and we never look back to date ... re-looping all packages paths might be doable but if micropip doesn't give us back pathe per package name, we can't check for anything in there
• previous point means if a package depends on another package with same dependency but different version:
  • we have no idea what should happen on the main thread
  • we have no idea how to handle different JS module for the same path
  • we are into dependencies injection hell that (imho) only top-level importer should care about, risking to break the rest of the code around
• we currently support CSS related modules too per each JS package, where is that reflected as dependency as most Web dependent modules might trust their related CSS was there too?

These are all issues we've solved already via our config, but while I like the direction this discussion is taking, I want to be sure all our previous discussions are taken into account too.

How about we update the manifest schema to closely match the relevant parts of pyscript.toml? I don't have a good reason for choosing .json; my only goal was to describe a static manifest containing a data structure, metadata, that runtimes can read without executing any .py or .js code.

well, we don't [know dependencies paths]

Interesting, ok, we want micropip to give us an array of the installed dependency names. Then, can we use python's import resolver to locate each module to read its metadata? importlib.util.find_spec(dependency_name)?

Or, alternatively, can we find every sys.path[*]/*/env.json or something similar? Since, as far as I understand, all dependencies are imported from subdirectories of sys.path entries.

Looks like micropip.list() returns a list of dependencies. But I'm not sure the paths we get from find_spec will reliably point to the root directory of the wheel.

import micropip
import importlib
import pkgutil
deps = micropip.list()
print(deps)
for depName, dep in deps.items():
    print(importlib.util.find_spec(depName))

if a package depends on another package with same dependency but different version

I thought python did not support this, that you can only have one version of each library loaded into the runtime.

those are indirect dependencies ... if Python guarantees once a version of any package is granted and reflected all over other dependencies, then yes, we can scratch that from my list of "what if" but about list, that's both good news but most complains around Pyodide are around bootstrap time + we would like to have feature parity with mip (the MicroPython counterpart) so ... investigation and some benchmark needed, but that might be it for Pyodide at least ... let's see!