Skip to content

Support PEP420 (implicit namespace packages) as --pyargs target. #13426

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Support PEP420 (implicit namespace packages) as --pyargs target. #13426

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions AUTHORS
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -134,6 +134,7 @@ Deysha Rivera
Dheeraj C K
Dhiren Serai
Diego Russo
Dima Gerasimov
Dmitry Dygalo
Dmitry Pribysh
Dominic Mortlock
Expand Down
1 change: 1 addition & 0 deletions changelog/478.feature.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1 @@
Support PEP420 (implicit namespace packages) as `--pyargs` target.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we add a section to the docs related to this support somewhere in the docs?

14 changes: 11 additions & 3 deletions src/_pytest/main.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -991,11 +991,19 @@ def search_pypath(module_name: str) -> str | None:
# ValueError: not a module name
except (AttributeError, ImportError, ValueError):
return None
if spec is None or spec.origin is None or spec.origin == "namespace":

if spec is None:
return None
elif spec.submodule_search_locations:
return os.path.dirname(spec.origin)
elif (
spec.submodule_search_locations is not None
and len(spec.submodule_search_locations) > 0
):
# If submodule_search_locations is set, it's a package (regular or namespace).
# Typically there is a single entry, but documentation claims it can be empty too
# (e.g. if the package has no physical location).
return spec.submodule_search_locations[0]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps instead of just returning it blindly, we should check if this is a directory before returning?

else:
# Must be a simple module.
return spec.origin


Expand Down
7 changes: 6 additions & 1 deletion testing/test_main.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -169,8 +169,13 @@ def test_dir(self, invocation_path: Path) -> None:
):
resolve_collection_argument(invocation_path, "src/pkg::foo::bar")

def test_pypath(self, invocation_path: Path) -> None:
@pytest.mark.parametrize("namespace_package", [False, True])
def test_pypath(self, namespace_package: bool, invocation_path: Path) -> None:
"""Dotted name and parts."""
if namespace_package:
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I kind of piggybacked on the existing test that covers this functionality, but not sure whether it's a bit dirty!
Please let me know if you'd prefer me to do it in some other way, e.g. create a new fixture specifically for this case. Or perhaps this should be tested in some different place rather than test_main?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @karlicoss,

I think it is perfectly fine to reuse an existing test like this one, thanks!

However functionality related to collection and packages tends to break complex test suites in subtle ways... been there done that.

But to be honest not sure how we can even foresee how this will be handled in the wild, unless we put it in the wild.

I'm considering adding this behind a feature flag, so if it causes havoc, we can optionally revert it...

On the other hand, we can just bite the bullet and see. If this causes massive breakage, we can always revert the patch and make a hot fix.

Just thinking aloud here.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On the other hand, we can just bite the bullet and see. If this causes massive breakage, we can always revert the patch and make a hot fix.

No, agree, it makes a lot of sense! From experience, such random breakages are pretty annoying. Happy to implement a feature flag and add documentation for it.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've been thinking about the flag name & documentation.. and actually, perhaps it makes sense to simply reuse consider_namespace_packages?

From my experience with it, right now only helps with package/module names. E.g. if there is a test inside test_pkg.py

src/
    pkg/
        test_pkg.py

And we run PYTHONPATH=src pytest --pyargs pkg.test_pkg

It correctly discovers tests in both cases, but.

  • with consider_namespace_packages, it has __package == "pkg" and __module__ == "pkg.test_pkg" (as one might expect)

  • without consider_namespace_packages, it has __package == "" and __module__ == "test_pkg"

    If we add pkg/__init__.py, this has correct __package__ and __module__ though.

This is consistent with --help:

Consider namespace packages when resolving module names during import

However, according to https://docs.pytest.org/en/stable/reference/reference.html#confval-consider_namespace_packages

Controls if pytest should attempt to identify namespace packages when collecting Python modules. Default is False.
Set to True if the package you are testing is part of a namespace package.

So the docs say it "should attempt to idenfity when collecting", but I'm not sure what this actually means here.

E.g. if you have the following hierarchy:

src/
    pkg/
        __init__.py
        subpkg/
            test_subpkg.py

pkg is a regular package with __init__.py, but pkg.subpkg is a namespace subpackage.
Then if you run PYTHONPATH=src pytest --pyargs pkg (with upstream pytest), pytest correctly discovers the test in test_subpkg.py

The only difference is

  • with consider_namespace_packages it correctly sets __package__ and __module__ in test_subpkg.py
  • without, it sets __package__ = ""

From a lurk in pytest code, to me it feels that indeed it has to do more with naming than test discovery -- e.g. I think stuff in this file is mostly after we already collected candidate files to run?

pytest/src/_pytest/pathlib.py

Line 494 in 83536b4

consider_namespace_packages: bool,

So perhaps if I just reuse consider_namespace_packages, this makes it closer to the original intent? So it could both discover tests under namespace packages (this PR), and they also will have correct __package__/__module__ attributes (already working in upstream pytest).

This also limits the potential impact from the change -- there are "only" 400ish matches for this setting on github https://github.com/search?q=consider_namespace_packages&type=code (tiny amount comparing to total pytest users), and I'd imagine people who use this setting know what they are doing anyway.

What do you think?

# Namespace package doesn't have to contain __init__py
(invocation_path / "src/pkg/__init__.py").unlink()

assert resolve_collection_argument(
invocation_path, "pkg.test", as_pypath=True
) == CollectionArgument(
Expand Down