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]

@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]

Please rename these to indicate they are modules and don't have confusing name duplication with the parent package.

[LecrisUT]

Don't you want to from .c_mod import square (renaming the subpkg1.c because it's confusing). This would be testing the navigation from python package to module.

[LecrisUT]

Can the name of the python packages be renamed to something less verbose? Maybe foo.bar.baz or subA.subB.modC or any convention you can think of. pkg.subpkg2.subsubpkg1.subsubpkg1 is a bit much.

[LecrisUT]

I am wondering if all of these imports should be merged into the import pkg or if the __init__.py should be empty. Feels weird having it duplicated. I am leaning towards the former because we could make the imports be relative or absolute or ambiguous using an environment variable.

[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.