-
-
Notifications
You must be signed in to change notification settings - Fork 631
Smarter namespace pkg detection in pip_install (issue #381) #483
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.
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
Conversation
actual = namespace_pkgs.implicit_namespace_packages(directory.root()) | ||
self.assertEqual(actual, expected) | ||
|
||
def test_skips_ignored_directories(self): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Test case is not really related to these changes, but should have been added before.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM thanks.
dir_includes_py_modules = _includes_python_modules(filenames) | ||
parent_of_namespace_pkg = any(str(pathlib.Path(dirpath, d)) in namespace_pkg_dirs for d in dirnames) | ||
parent_of_standard_pkg = any(str(pathlib.Path(dirpath, d)) in standard_pkg_dirs for d in dirnames) | ||
parent_of_pkg = parent_of_namespace_pkg or parent_of_standard_pkg |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: if this is the only use of this variable it seems cleaner to put it in the conditional where it is used.
@thundergolfer, the azure namespace packages were working for me with rules_python 0.2.0, but quit working with rules_python 0.3.0, which includes this PR. I am not sure if that is the expected behavior, so I'd like to report the results here instead of creating a new issue. In short, the
is no longer being added to:
Thus
I've attached python_namespace_package.zip which contains five files (BUILD, requirements.in, requirements.txt, test_mlflow_import.py, and WORKSPACE) for reproducing this issue. You can use commenting to switch them between rules_python 0.2.0 and 0.3.0. Please let me know if rules_python 0.3.0 is behaving as expected, or if I should create a new issue. |
@thundergolfer, I was using Thanks for pointing out #499. I checked For the test case, you can start with mlflow==1.13.1 and setuptools==54.0.0 in requirements.in and use |
PR Checklist
Please check if your PR fulfills the following requirements:
.par
files. See CONTRIBUTING.md for infoPR Type
What kind of change does this PR introduce?
What is the current behavior?
Issue Number: #381
(Issue contains a lot of detail so is worth reading for background)
What is the new behavior?
Packages like
ciso8601
which previously weren't handled correctly (see #381) now work correctly. Previouslypip_install
took any non-empty directory without__init__.py
to be a namespace package, which is wrong. A namespace package is a directory that either includes Python module files as immediate children, or is the parent directory of a directory which is a package (may be namespace or regular).Demo: https://github.com/thundergolfer-playground/rules_python-issue-381
Does this PR introduce a breaking change?