Skip to content

Use service titles in client package descriptions - #930

Closed
jonathan343 wants to merge 3 commits into
smithy-lang:developfrom
jonathan343:fix/package-description
Closed

jonathan343 wants to merge 3 commits into
smithy-lang:developfrom
jonathan343:fix/package-description

Conversation

@jonathan343

@jonathan343 jonathan343 commented Nov 12, 2026 •

Copy link
Copy Markdown
Contributor

Summary

Generated client descriptions currently repeat the module name, such as
aws_sdk_dynamodb client, rather than identifying the service in readable terms.

This PR uses the service's standard smithy.api#title trait to generate
Python client for <title> or Python types for <title>, falling back to the
service shape's name when no title is present. Types packages generated without
a selected service use the module name instead of the internal synthetic service
name. This works for AWS and non-AWS services. Package metadata and the generated
README share the same resolved description. Explicit moduleDescription
overrides are unchanged.

Example

For Amazon DynamoDB, the generated pyproject.toml changes from:

description = "aws_sdk_dynamodb client"

To:

description = "Python client for Amazon DynamoDB"

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Default client descriptions to the service title, with the service name
as a fallback. Share the resolved description between package metadata
and the README while preserving explicit overrides and types defaults.

@jonathan343 jonathan343 Nov 12, 2026 •

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Note: We should do a complete rehaul of the generated READMEs in a separate PR. This just improves what is there now since the description is already being used there.

Limit title-based descriptions to pyproject.toml metadata. Preserve the
existing README output for a separate documentation overhaul.
Resolve descriptions during setup generation, honoring overrides before
service titles and names. Use the module name for service-less types
packages, and share the result between metadata and README output.
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.

1 participant