-
-
Notifications
You must be signed in to change notification settings - Fork 644
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
Add the ability to infer assets from strings for Python #14049
Conversation
src/python/pants/backend/python/dependency_inference/dependency_parser.py
Outdated
Show resolved
Hide resolved
Can someone re-kick the tests? |
Will need to rebase I think: the fix for this landed on |
fc1cfd2
to
39b6655
Compare
I suppose rebasing is an easy re-kick. 🙌 |
f124689
to
84e1791
Compare
python_sources( | ||
overrides={ | ||
"parse_python_imports.py": { | ||
# This Python script is loaded as a resource, see parse_python_imports.py for more info. | ||
"dependencies": ["./scripts:import_parser"] | ||
} | ||
} | ||
) |
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.
You might ask where this has gone. The answer: it's being inferred 🪄
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.
Looking good. Haven't worked through it all in details, though.. :)
src/python/pants/backend/python/dependency_inference/scripts/dependency_parser.py
Show resolved
Hide resolved
8701b2c
to
8bdeb7a
Compare
src/python/pants/backend/python/dependency_inference/scripts/dependency_parser.py
Outdated
Show resolved
Hide resolved
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.
Neat! Iirc, this would not handle this: importlib.resources.read_text("path.to.module", "foo.txt")
, right? Even if not, this is still great.
src/python/pants/backend/python/dependency_inference/parse_python_deps.py
Outdated
Show resolved
Hide resolved
src/python/pants/backend/python/dependency_inference/parse_python_deps_test.py
Outdated
Show resolved
Hide resolved
It does not. I didn't want to risk adding too many things to this PR, and import inference doesn't support |
Makes sense. Only thing we need to be careful about is how to handle backwards-compatibility. If we change the behavior of this new option to become more powerful / infer more than before, that is somewhat a breaking change. I think it's acceptable, but we should probably hedge in the
|
That's likely to be true of |
Yes. I think we weren't considering how I'm pretty sure it doesn't break our deprecation policy, only a possible gotcha. Maybe the second sentence in my suggested language isn't necessary, but probably good to have the first one. |
Yeah OK I think this is likely the route to take. I'll most likely post a new PR for that since the changes will be somewhat drastic. 🤞 hopefully there isn't too much duplication between this and import parsing. |
I don't think I agree with splitting out the parsing into two separate Instead, it's important that the parser do the minimum work necessary. If you don't care about resources, then don't try to parse them. It looks like you already made that optimization.
That sounds like it might be more complex. What would be the benefit? |
It's more about simplification and separation of concerns. The Perhaps splitting it into helpers (not necessarily needing #14238 but that'd be even nicer) would qualm some doubts. For implementations sake, you might be right that bundling them together is still simpler. |
OK I did another once-over on the PR. Should be good to re-review. Let me know if it needs to be split. |
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.
🥳
src/python/pants/backend/python/dependency_inference/scripts/dependency_parser.py
Outdated
Show resolved
Hide resolved
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.
Ability to infer both resources (assumed to be relative to the module, unless pkgutil.get_data is used) and files
Is the PR description still up-to-date? I'm not following the code for this part.
Generally, it seems that this only infers in the format path/to/f.txt
, not path.to.my_resource
, right?
Fixed the wording |
src/python/pants/backend/python/dependency_inference/parse_python_dependencies.py
Outdated
Show resolved
Hide resolved
src/python/pants/backend/python/dependency_inference/parse_python_dependencies.py
Outdated
Show resolved
Hide resolved
src/python/pants/backend/python/dependency_inference/parse_python_dependencies.py
Outdated
Show resolved
Hide resolved
src/python/pants/backend/python/dependency_inference/scripts/dependency_parser.py
Outdated
Show resolved
Hide resolved
# Rust tests and lints will be skipped. Delete if not intended. [ci skip-rust] # Building wheels and fs_util will be skipped. Delete if not intended. [ci skip-build-wheels]
@@ -31,21 +32,37 @@ class ParsedPythonImports(FrozenDict[str, ParsedPythonImportInfo]): | |||
"""All the discovered imports from a Python source file mapped to the relevant info.""" | |||
|
|||
|
|||
class ParsedPythonAssets(DeduplicatedCollection[str]): |
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.
Maybe ParsedPythonAssetPaths
? I continue to confuse myself with what this is, I think because of the old setup of it being a tuple.
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.
Yeah. If/when we support pkgutil.get_data
we'll be changing this name 😅 but for now that works!
@@ -89,6 +103,24 @@ class PythonInferSubsystem(Subsystem): | |||
"treated as a potential dependency if this option is set to 2 but not if set to 3." | |||
), | |||
) | |||
assets = BoolOption( | |||
"--assets", | |||
default=False, |
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.
If you didn't have to consider our deprecation policy, should this default to True? We don't have string imports default to True because of false positives. Not sure what the right behavior is here.
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.
Yeah. OK. I can get very behind making True
the default.
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.
Ah, but note that we do need to consider our deprecation policy, I think. Possibly. Unclear to me. I was only asking what the aspiration is.
In the interest of landing this for 2.10, how about using False
for now, having a conversation in Slack or dedicated PR on Monday, and then possibly changing it in time for 2.10? That'd be good anyways to have two entries in changelog:
# new feature
* Add `[python-infer].assets` to infer resources and files from strings
# user-api changes
* Enable `[python-infer].assets` by default
# Rust tests and lints will be skipped. Delete if not intended. [ci skip-rust] # Building wheels and fs_util will be skipped. Delete if not intended. [ci skip-build-wheels]
# Rust tests and lints will be skipped. Delete if not intended. [ci skip-rust]
Updated with:
|
# Rust tests and lints will be skipped. Delete if not intended. [ci skip-rust] # Building wheels and fs_util will be skipped. Delete if not intended. [ci skip-build-wheels]
# Rust tests and lints will be skipped. Delete if not intended. [ci skip-rust] # Building wheels and fs_util will be skipped. Delete if not intended. [ci skip-build-wheels]
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.
Thank you for iterating on this! Looks good once the default
is reverted to not break our deprecation policy.
This reverts commit d588e39. [ci skip-rust]
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.
🎉
Woohoo!! |
High level
Although less structured, it shouldn't be difficult to infer assets from strings and filter the noise to only what is valid.
The use-case should be evident, however here's a few intentional design decisions:
pkgutil.get_data
) because some people use custom resource types. E.g.Resource("data/foo.txt")
. We can addpkgutil.get_data
support later.Example:
Given:
(With all the right
BUILD
file plumbing)Then
src/app1/app.py
containing code likeopen("configs/prod.txt") as envvars
orDatabase("data/db.json")
would have the relevant file/resource dependency inferred by Pants! 🎉