Skip to content
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 support for external_packages to Python so Python packages can … #1784

Merged
merged 1 commit into from
Oct 18, 2023

Conversation

mhammond
Copy link
Member

@mhammond mhammond commented Oct 9, 2023

…be used.

When using external types, the expectation is that most consumers will want to use a Python package which holds all the modules - therefore, imports for external types defaults to from .module import name. This behaviour can be changed to support any package name, including just doing a regular top-level module import - which we leverage for some tests.

Fixes #1776

(While this seems sensible to me, feel free to push back on either the implementation or the default)

@mhammond mhammond requested review from badboy and jeddai October 9, 2023 17:50
@mhammond mhammond requested a review from a team as a code owner October 9, 2023 17:50
Copy link
Contributor

@jhugman jhugman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good to me! Also: nice docs!

Comment on lines +101 to +108
pub fn module_for_namespace(&self, ns: &str) -> String {
let ns = ns.to_string().to_snake_case();
match self.external_packages.get(&ns) {
None => format!(".{ns}"),
Some(value) if value.is_empty() => ns,
Some(value) => format!("{value}.{ns}"),
}
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Neat.

Copy link
Member

@badboy badboy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

small note, but otherwise good to go!

@@ -8,10 +8,34 @@ The generated Python modules can be configured using a `uniffi.toml` configurati
| ------------------ | ------- |------------ |
| `cdylib_name` | `uniffi_{namespace}`[^1] | The name of the compiled Rust library containing the FFI implementation (not needed when using `generate --library`). |
| `custom_types` | | A map which controls how custom types are exposed to Python. See the [custom types section of the manual](../udl/custom_types#custom-types-in-the-bindings-code)|
| `external_packages` | `.` | A map which controls the package name used by external packages.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a bit confusing in the docs, the default is given as . but the text says this should be a map.
I would expect that I can set external_packages = "." to get the same default behavior, but that doesn't work.
And thus now from only the docs it's not clear how to configure this. It's then explained in the next lines, maybe the table should call this out? "Look further down for details"

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, thanks, I made a few other tweaks to make that clearer too.

…be used.

When using external types, the expectation is that most consumers will
want to use a Python package which holds all the modules - therefore,
imports for external types defaults to `from .module import name`.
This behaviour can be changed to support any package name, including
just doing a regular top-level module import - which we leverage for
some tests.

Fixes mozilla#1776
@mhammond mhammond merged commit ca35eda into mozilla:main Oct 18, 2023
@mhammond mhammond deleted the python-package branch October 18, 2023 20:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

External types seem to prevent (easy) distribution
3 participants