Generate entry_points.txt for python_tests that require entry points from a python_distribution#21062
Generate entry_points.txt for python_tests that require entry points from a python_distribution#21062cognifloyd merged 27 commits intomainfrom
Conversation
c479815 to
4405d7d
Compare
a4bf6bd to
5fe939d
Compare
The new python_tests entry_point_dependencies field will need almost the same logic as the stevedore plugin, so extract the logic into a reusable rule. Also, extract a helper function from the shared logic in infer_python_distribution_dependencies.
to allow short circuiting as much as possible
generates entry_points.txt files
mypy cannot tell that these Targets are PythonDistributions And fix several actual typos or errors
A helper function has to be defined before the rule that uses it. Otherwise, the pants engine cannot detect it.
If there's nothing to generate, stop. If no entry points were found, skip the group. If the generated file ends up being empty, skip it. If no files were generated, use EMPTY_DIGEST.
So register them with the experimental backend for now. Once util_rules.entry_points graduates to the official backend, we can drop target_types_rules from the experimental backend.
5fe939d to
74cf92f
Compare
src/python/pants/backend/experimental/python/framework/stevedore/register.py
Show resolved
Hide resolved
| ) -> tuple[ | ||
| Targets, PythonDistributionEntryPointGroupPredicate, PythonDistributionEntryPointPredicate | ||
| ]: | ||
| assert entry_point_deps.value, "Unexpected empty entry_point_dependencies field" |
There was a problem hiding this comment.
How does this manifest to the user? (i.e. is this possible with BUILD file (mis)configuration? or is it merely a sign of an internal pants bug?)
What I'd prefer is to have the error message convey if this is in any way fixable when encountered, or if it's an internal bug and they need to turn to the pants project for assistance/report a bug.
There was a problem hiding this comment.
This serves to narrow the types for mypy. Everywhere that could call this rule bails out before calling it if the field is empty (See infer_entry_point_dependencies and generate_entry_points_txt_from_entry_point_dependencies). So, I expect this to only ever happen during development, not a released version.
Maybe I could raise an exception like InvalidField. Would that be better?
There was a problem hiding this comment.
I turned this into a more verbose ValueError. Thanks for the suggestion.
There was a problem hiding this comment.
Ah, right. In that case, I think an assert is just fine, as we don't expect to ever hit it, and it's presence is only to satisfy mypy. I've done the same, but leaving a hint as to why it's there (and thus, no assert message, as it's not supposed to ever hit):
This adds a new
entry_point_dependenciesfield topython_testsandpython_testtargets.This allows tests to depend on a subset (or all) of the
entry_pointsdefined onpython_distributiontargets (only on theentry_pointsfield, not in theprovidesfield).For example:
A dependency defined in
entry_point_dependenciesemulates an editable install of thosepython_distributiontargets. Instead of including all of thepython_distribution's sources, only the specified entry points are made available. The entry_points metadata is also installed in the pytest sandbox so that tests (or the code under test) can load that metadata viapkg_resourcesorimportlib.metadata.entry_pointsor similar.Misc notes:
pants.backend.experimental.pythonbackend and also registered the rules I extracted frompants.backend.experimental.python.framework.stevedorewith the stevedore backend since it needs those rules.entry_point_dependenciesis adict[str, list[str]]. The.keys()of the dict are logically similar to standard dependencies fields. Using a dict provides more granular control over the dependencies.python_distributiontarget. Instead, that target provides theentry_pointsmetadata to infer dependencies on the actual code for those entry points.Closes #11386
Closes #15481