optionally override module names; bump version to 0.16.0 #128
Conversation
This file contains 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 adds CLI and componentize-py.toml options for overriding the generated Python module names for one or more WIT interfaces. By default, the name is the snake-case version of the WIT name, qualified as necessary with the package namespace and name and/or the version in cases of ambiguity. Sometimes that's not what you want, though, so now you can override the naming on an individual basis as long as the name(s) you pick are unique. This can be especially useful for backwards compatibility when adding new versions of WIT interfaces. In that case, the generated module name may go from unqualified to qualified, but you can now force the name of the original version to be unqualified for compatibility. For example: - You release an SDK with an interface called `foo:bar/baz@1.0.0`. Since that's the only interface with the name `baz`, `componentize-py` will name the generated module `baz` also. - Later, you release a new version of the SDK with support for _both_ `foo:bar/baz@1.0.0` _and_ `foo:bar/baz@2.0.0`. In that case, `componentize-py` will name the generated modules `foo_bar_baz_1_0_0` and `foo_bar_baz_2_0_0` by default. However, you don't want to force users of your SDK to use the new name, so you pass `--import-interface-name foo:bar/baz@1.0.0=baz` to `componentize-py`, which tells it to use the original name. Signed-off-by: Joel Dice <joel.dice@fermyon.com>
dicej
added a commit
to dicej/spin-python-sdk
that referenced
this pull request
Nov 27, 2024
This adds support for fermyon:spin@3.0.0 worlds, while still using the 2.0.0 worlds by default. Apps may opt-in to using a 3.0.0 world by specifying e.g. `--world fermyon:spin/spin-http@3.0.0` as part of their `componentize-py` command in their `spin.toml` file. This also updates to `componentize-py` v0.16.0 (which includes bytecodealliance/componentize-py#128, a feature required for compatibility with earlier SDK releases). Signed-off-by: Joel Dice <joel.dice@fermyon.com>
i.e. match what we're doing in release.yaml. TODO: Factor out the "Populate cache" job into a reusable action instead of cut-and-pasting it. Signed-off-by: Joel Dice <joel.dice@fermyon.com>
dicej
added a commit
to dicej/spin-python-sdk
that referenced
this pull request
Nov 27, 2024
This adds support for fermyon:spin@3.0.0 worlds, while still using the 2.0.0 worlds by default. Apps may opt-in to using a 3.0.0 world by specifying e.g. `--world fermyon:spin/spin-http@3.0.0` as part of their `componentize-py` command in their `spin.toml` file. This also updates to `componentize-py` v0.16.0 (which includes bytecodealliance/componentize-py#128, a feature required for compatibility with earlier SDK releases). Signed-off-by: Joel Dice <joel.dice@fermyon.com>
dicej
added a commit
to fermyon/spin-python-sdk
that referenced
this pull request
Dec 3, 2024
This adds support for fermyon:spin@3.0.0 worlds, while still using the 2.0.0 worlds by default. Apps may opt-in to using a 3.0.0 world by specifying e.g. `--world fermyon:spin/spin-http@3.0.0` as part of their `componentize-py` command in their `spin.toml` file. This also updates to `componentize-py` v0.16.0 (which includes bytecodealliance/componentize-py#128, a feature required for compatibility with earlier SDK releases). Signed-off-by: Joel Dice <joel.dice@fermyon.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This adds CLI and componentize-py.toml options for overriding the generated Python module names for one or more WIT interfaces.
By default, the name is the snake-case version of the WIT name, qualified as necessary with the package namespace and name and/or the version in cases of ambiguity. Sometimes that's not what you want, though, so now you can override the naming on an individual basis as long as the name(s) you pick are unique.
This can be especially useful for backwards compatibility when adding new versions of WIT interfaces. In that case, the generated module name may go from unqualified to qualified, but you can now force the name of the original version to be unqualified for compatibility. For example:
You release an SDK with an interface called
foo:bar/baz@1.0.0. Since that's the only interface with the namebaz,componentize-pywill name the generated modulebazalso.Later, you release a new version of the SDK with support for both
foo:bar/baz@1.0.0andfoo:bar/baz@2.0.0. In that case,componentize-pywill name the generated modulesfoo_bar_baz_1_0_0andfoo_bar_baz_2_0_0by default. However, you don't want to force users of your SDK to use the new name, so you pass--import-interface-name foo:bar/baz@1.0.0=baztocomponentize-py, which tells it to use the original name.