-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Fix bug that prevents packages.find.exclude
to take effect when include_package_data=True
#3261
Conversation
prev = d | ||
d, df = os.path.split(d) | ||
f = os.path.join(df, f) | ||
|
||
if d in src_dirs: | ||
if path.endswith('.py') and f == oldf: |
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.
Side note
This f == oldf
condition is a bit odd.
According to the git history (f01c17e), the original intention of this code was to:
Allow .py files found by the include_package_data option to be automatically included.
To me that sounds a little bit as a misuse. My opinion is that modules should not be affected by include_package_data
...
Unfortunately, I cannot find the original repository (I guess it was bitbucket) to check if it was associated with a PR or feature request to understand the context.
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.
All of the issues and PRs were migrated from Bitbucket, but that commit comes from when Setuptools was hosted on Sourceforge and Subversion, where issues and merges weren't tracked as easily, so the commit history is the best we have.
part.isidentifier() | ||
for part in potential_module.relative_to(directory).with_suffix("").parts | ||
) | ||
for potential_module in Path(directory).glob("**/*.py") |
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.
Here I thought about checking against importlib.machinery.all_suffixes
, but I decided to go only with .py
because I don't know what to do with .so
files...
(Maybe the .so
is not generated by setuptools, but instead compiled out-of-band and included by the user on purpose?)
Hi @jaraco, would it be possible for you to have a look in this PR? There is some very old implementation involved in the faulty behaviour so I am not exactly sure if the provided patch is the best way to go (but is the only way I can imagine 😅) |
Fix bug that prevents `packages.find.exclude` to take effect when `include_package_data=True`
I'll plan to look today. |
Today is not going as planned. Maybe tomorrow. |
No problems Jason, whenever you have the time. It is not something urgent, I was just not confident enough with the change to merge it directly. Thank you very much. |
Thanks for this proposal. Your patch made it easy to see the intention here. In the referenced issue, I wrote a response about the problem generally, where I expressed my reservations. In spite of those reservations, I'd be open to merging this change and rolling it out to see what impact it has. Even if not optimal, perhaps this proposed behavior is preferable to the prior behavior. Either way, I'd like us at some point to explore a redesign of the mechanisms for determining the 'build' manifest. |
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.
Tiny typo :)
Thank you very much @jaraco. There is an alternative implementation: we can consider all nested folders as nested packages, and avoid traversing them in the first place. In terms of implementation it would mean removing this loop: setuptools/setuptools/command/build_py.py Lines 137 to 140 in 372652d
I think this behaviour would is more intuitive and reflects better what I expect from
I am more than open to work on that. Do you have something in mind? |
Co-authored-by: Aarni Koskela <akx@iki.fi>
I don’t have anything specific in mind at this time. I’ll defer to your judgment. I’m okay with disruptive as long as we manage the disruption. |
Thank you very much @jaraco. I changed the PEP 660 implementation proposal to not depend on this PR. I think the right thing going forward is to treat any folder that is importable to Python as a package and therefore subject to the expected effects. I plan to implement the following strategy in the following days:
|
I have created #3308 to start with a deprecation warning. After some time (during which the users have the chance to do the necessary changes), we can revisit the topic and fix the bug. @jaraco what is the release policy for setuptools in terms of deprecations? Is there a target in terms of recommended time interval (or number of major versions) between deprecating a behaviour/mechanism and its removal from setuptools? |
Summary of changes
When discovering files in
build_py
, avoid including files and directories that correspond to a sub-package.This way excluded sub-packages are automatically ignored.
Closes #3260.
Pull Request Checklist
changelog.d/
.(See documentation for details)