-
Notifications
You must be signed in to change notification settings - Fork 522
feat: pyo3 support module prefix + naming #3726
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
Open
andyscott
wants to merge
2
commits into
bazelbuild:main
Choose a base branch
from
andyscott:ags/pyo3-module-path
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
+75
−6
Open
Changes from all commits
Commits
Show all changes
2 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,17 @@ | ||
| load("@rules_python//python:defs.bzl", "py_test") | ||
| load("//:defs.bzl", "pyo3_extension") | ||
|
|
||
| pyo3_extension( | ||
| name = "module_prefix", | ||
| srcs = ["bar.rs"], | ||
| edition = "2021", | ||
| imports = ["."], | ||
| module = "bar", | ||
| module_prefix = "foo", | ||
| ) | ||
|
|
||
| py_test( | ||
| name = "module_prefix_import_test", | ||
| srcs = ["module_prefix_import_test.py"], | ||
| deps = [":module_prefix"], | ||
| ) | ||
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,12 @@ | ||
| use pyo3::prelude::*; | ||
|
|
||
| #[pyfunction] | ||
| fn thing() -> PyResult<&'static str> { | ||
| Ok("hello from rust") | ||
| } | ||
|
|
||
| #[pymodule] | ||
| fn bar(m: &Bound<'_, PyModule>) -> PyResult<()> { | ||
| m.add_function(wrap_pyfunction!(thing, m)?)?; | ||
| Ok(()) | ||
| } |
19 changes: 19 additions & 0 deletions
19
extensions/pyo3/test/module_prefix/module_prefix_import_test.py
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,19 @@ | ||
| """Tests that a pyo3 extension can be imported via a module prefix.""" | ||
|
|
||
| import unittest | ||
|
|
||
| import foo.bar # type: ignore | ||
|
|
||
|
|
||
| class ModulePrefixImportTest(unittest.TestCase): | ||
| """Test Class.""" | ||
|
|
||
| def test_import_and_call(self) -> None: | ||
| """Test that a pyo3 extension can be imported via a module prefix.""" | ||
|
|
||
| result = foo.bar.thing() | ||
| self.assertEqual("hello from rust", result) | ||
|
|
||
|
|
||
| if __name__ == "__main__": | ||
| unittest.main() |
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
Why add these attributes and not change the target name to
foo/bar?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.
I tried that first, e.g. for
string_sum:Building that target yields this error:
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.
There were several quirks with getting the names to line up (pymodule <-> output binary <-> crate name) + getting the outputs in the right directory so Python registers it as nested module rather than a top level module. Adding these (hopefully simple) knobs seemed like the cleanest approach.
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.
I'm nervous about the amount of indirection this introduces. What is the use case here that directory structure can't be made to what you want?
Uh oh!
There was an error while loading. Please reload this page.
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.
I'm not sure I follow w.r.t. indirection. This change tackles two related issues on how the native extension gets imported:
(1)
Per the pyo3 docs, the lib name must match the pymodule definition.
As it stands with rules_rust the target name was being used to determine the final extension file path. Imagine you have a python library "foo" that has regular python code + a private extension you want to import as "_foo_internal". You'd have to declare your extension as follows:
The underscore prefix on the bazel target implies that it's not a first class target in the build graph when this is definitely not the case. Related, build generators often want to follow nice patterns for generated targets. So imagine we generated
<name>_pyo3_extfor all pyo3 extensions-- this would mean out python import path also has the same suffix. The current behavior is tolerable but somewhat quirky and undesirable.(2)
As for the second issue, to get a rust extension importable/loadable at a full module path you need to place the lib in the nested directory structure. Roughly:
The current rules don't give you control over the output path of the extension, so the best you could do is to manually move the file in a subsequent target. But injecting my own copy on top of these rules would nuke the python providers (and the stub generation) as they just assume a root module.
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.
One thing I can think of to make the UX of this change a bit cleaner is to squash the two params into one, e.g.
module = "foo.bar"and then the rules/macros can split accordingly.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.
By indirection I mean a developers ability to understand where a target came from. Seeing
//:well_hello_therein as a bazel target and then in python code seeingthe.rebel.allianceI think is going to lead to more confusion than it's worth for the alternate import path. What is the story for how folks are expected to understand where code is being defined?Uh oh!
There was an error while loading. Please reload this page.
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.
Sure, but that's a pretty egregious example I think. The naming is purposefully confusing and something folks can already do freely across most Bazel repos. Take
rust_binaryor any binary rule for that matter:I don't want to configure my pyo3 extension targets in any purposefully confusing manner; I want to name them so the Bazel side is idiomatic for Bazel and the Python side is idiomatic for our Python usage.
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.
I'm not suggesting you're trying to do something malicious or anything haha. I've had a similar experience with pybind11 rules and it was incredibly frustrating where two different teams adopted two different naming conventions and debugging issues became harder for no meaningful reason. I opted to have them define a file with the name they wanted and reexport all symbols so there was a clear path to follow.
However, if this feature is strongly desired then I'd prefer there to just be
module_name(matching thecrate_nameattribute) to be the fully qualified module name (combined prefix and name).