`stack-data`'s dependency map is wrong

[Muspi Merol]

🐛 Bug

stack-data is directly dependent on pure-eval, executing and asttokens. But the requirements field in meta.yaml is empty.

To Reproduce

import stack_data

Expected behavior

Traceback (most recent call last):
  File "<console>", line 1, in <module>
    import stack_data
  File "/lib/python3.12/site-packages/stack_data/__init__.py", line 1, in <module>
    from .core import Source, FrameInfo, markers_from_ranges, Options, LINE_GAP, Line, Variable, RangeInLine, \
  File "/lib/python3.12/site-packages/stack_data/core.py", line 15, in <module>
    import executing
ModuleNotFoundError: No module named 'executing'

Environment

• Pyodide Version: 0.26.1
• Browser version: Microsoft Edge 126.0.2592.81
• Any other relevant information:

Additional context

[Gyeongjae Choi]

Thanks for finding this out! I believe we do some basic import tests for all packages, so it's strange that this was not catched in CI.

[Hood Chatham]

Well it doesn't have a test/imports section:

test:
  imports:
    - stack_data

[Muspi Merol]

Only 33/267 packages has test/imports key. Why don't just test at least every package/top-level keys? Or test/imports can defaults to package/top-level?

[Hood Chatham]

Sounds pretty reasonable.

[Muspi Merol]

pyodide/packages/_tests/test_packages_common.py

Lines 89 to 97 in 9428c6f

  
 import_names = meta.test.imports 
 if not import_names: 
     import_names = meta.package.top_level 
  
 if not import_names: 
     # Nothing to test 
     return 
  

It seems we already have this logic 🤔

[Gyeongjae Choi]

It's because the name of the stack-data package is misconfigured in meta.yaml file. It should be stack-data not stack_data, which made our test bypass that package. There seem to be other packages that have the same issue as well, like smart_open and python_solvespace. I guess we need some test for it.