Add more tests of package traversal

[vyasr]

This PR adds tests (including some xfailed ones) demonstrated patterns of package/subpackage access via import and importlib that are expected to work correctly for both normal and editable installs. Related to #807.

[vyasr]

@LecrisUT this PR should capture some of the cases you mentioned in #808 (comment). Are there others that you would like to see added?

[LecrisUT]

Looks promising :). I'll need to draw it out on a paper to follow it 😅 , I'll come back to you after that. At first glance, I think the only part not covered is having both relative and absolute paths in the __init__.py, but maybe that is sufficiently covered by the other test.

[LecrisUT]

This should be assert instead of print. Could you also move check to be in-lined here instead of a parameter?

[vyasr]

Rather than asserting here, I print the boolean result and assert the string value outside because asserting inside a subprocess requires significantly more post-processing to handle cleanly.

[LecrisUT]

Could you elaborate on why it requires more post-processing, or what the output you get when doing that?

[vyasr]

I take it back. I originally said this because while debugging specific cases it was more challenging to extract information from subprocess exceptions than to simply parse inputs and outputs to run inside the environment, but in the final state the output is sufficiently readable as is. I've moved the assert.

Could you also move check to be in-lined here instead of a parameter?

I don't understand this suggestion. check is parametrized, so how would I inline it without duplicating the test?

[LecrisUT]

What I was suggesting is to not parametrize it, and instead write all of the checks explicitly in the isolated.execute part

[vyasr]

@henryiii this is currently a draft mostly so that I can collect ideas from you and @LecrisUT on other tests we might want to add, so let me know what you think and I can update this PR accordingly before opening it up for review.

[LecrisUT]

Regarding the coverage, right now it seems the import only cover python packages, the c methods must also be imported there.

Most of the imports only cover 1 level deep imports, and are a bit redundant. I would say to minimize it and comment what is being covered:

# pkg/__init__.py

# Covering importing one-level deep from 1st level pakage
from .py_mod import py_square1
from .c_mod import c_square1

# Coverging importing 2-levels deep from 1st level package
from .subA.py_mod import py_square2
from .subA.c_mod import c_square2

# pkg/subA/__init__.py

# Covering importing one-level deep from 2nd level pakage
from .py_mod import py_square3
from .c_mod import c_square3

# Coverging importing relative paths backwards
from ..subB.py_mod import py_square4
from ..subB.c_mod import c_square4

I suck at naming conventions, hope you can figure a good one.

[LecrisUT]

On the overall structure of the files, I think it's a good skeleton to cover all the cases, we just need to cover the navigations within there. Just a few notes:

• there are 2 files missing: a top-level py_mod.py and a top-level c_mod.c i.e. not belonging to pkg.*
• namespace packages are not covered:
  • src namespace packages, i.e. src1/pkg/py_modA.py + src2/pkg/my_modB.py that would be installed in site_packages/pkg/py_mod{A,B}.py and resolved as pkg.py_modA/pkg.py_modB
  • installed namespace packages, i.e. site_packages/other_pkg/py_mod{A,B}.py where there is no site_packages/other_pkg/__init__.py and those resolve as other_pkg.py_modA.py/other_pkg.py_modB.py. An example of this is jaraco.* packages.

[vyasr]

OK I think I've addressed most of the requests. Some notes:

• I have not yet included any imports traversing up the hierarchy because those would cause circular imports. I'm not sure how you'd like that to be handled here.
• I added the top-level pure and extension modules but I don't know what you'd like me to do with them.
• I haven't added namespace packages yet. I don't understand the importance of the src vs installed cases that you want to address.