Initial support for building dists using mypyc. #15380
Conversation
Handles setting up mypy and any necessary config, requirements and type stubs, so that a preexisting setup.py can call mypycify(). Does not handle supporting mypyc in generated setup.py files. That will be provided in a future change. Also fixes a bug where we did not set the sys.path correctly when running a preexisting setup.py that imported code from a different source root. Also switches a test to use provides=python_artifact(), which is what we document, instead of the older alias setup_py(). [ci skip-rust] [ci skip-build-wheels]
|
Related: #14752, which links to related and complementary work from @sureshjoshi, to whom thanks for ideas and inspiration for this. |
| # Get any extra build-time environment (e.g., native extension requirements). | ||
| build_env_requests = [] | ||
| build_env_request_types = union_membership[DistBuildEnvironmentRequest] | ||
| for build_env_request_type in build_env_request_types: |
There was a problem hiding this comment.
Note that, hypothetically at least, we support multiple build environments. E.g., a single setup.py could use mypyc and (in the future) cython...
|
|
# 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]
[ci skip-rust] [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]
Should this be cherry-picked to 2.11 or 2.12? |
| @@ -401,25 +425,66 @@ async def package_python_dist( | |||
| ), | |||
| ) | |||
|
|
|||
| # Find the source roots for the build-time 1stparty deps (e.g., deps of setup.py). | |||
There was a problem hiding this comment.
This is a pretty big rule, consider factoring out a @rule_helper. (Not sure that's the right call)
There was a problem hiding this comment.
This whole file is huge and needs refactoring, but I will hold off on that for now.
| class UsesMyPycField(BoolField): | ||
| alias = "uses_mypyc" | ||
| default = False | ||
| help = "If true, this distribution is built using mypyc." |
There was a problem hiding this comment.
What else would be relevant to a user? For example
- do we expect a hand-written setup.py / pyproject.toml? If so, with what content?
- clarifying it uses the version of
mypyfrom[mypy].version
There was a problem hiding this comment.
Added more detail.
# 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]
Handles setting up mypy and any necessary config, requirements
and type stubs, so that a preexisting setup.py can call
mypycify().
Takes advantage of our existing robust support for mypy.
Lays groundwork for supporting other special build-time
requirements, such as cython.
Does not handle supporting mypyc in generated setup.py files.
That will be provided in a future change.
Also fixes a bug where we did not set the sys.path correctly
when running a preexisting setup.py that imported code from
a different source root.
Also switches a test to use provides=python_artifact(), which
is what we document, instead of the older alias setup_py().
[ci skip-rust]
[ci skip-build-wheels]