Add Missing Dependencies In Codegen

[jonathan343]

Overview

When generating a client for a service that uses REST-JSON or AWS Event Streaming, the client is unusable after install (see "Error Examples" section below) due to nothing taking a dependency on smithy-json or smith-aws-event-stream.

This PR adds the following:

• Adds a json optional dependency group that includes smithy-json.
• Updates the code generator to include a smithy-aws-core[eventstream] dependency in pyproject.toml when operations with event streaming are added.
• Updates the code generator to include a smithy-aws-core[json] dependency in pyproject.toml when generating services that support REST-JSON.

Dependencies Before and After

Dependencies Before Fix

# in pyproject.toml

dependencies = [
    "smithy_aws_core<0.1.0",
    "smithy_core<0.1.0",
    "smithy_http[awscrt]<0.1.0"
]

Dependencies After Fix

# in pyproject.toml

dependencies = [
    "smithy_aws_core[eventstream, json]<0.1.0",
    "smithy_core<0.1.0",
    "smithy_http[awscrt]<0.1.0"
]

Error Examples

Error without smithy-json

ModuleNotFoundError: No module named 'smithy_json'

Error without smithy-aws-event-stream

smithy_core.exceptions.MissingDependencyError: Attempted to use event streams, but smithy-aws-event-stream is not installed.

Alternative Option

Add a direct dependency on smithy-json and smith-aws-event-stream:

# in pyproject.toml

dependencies = [
    "smithy_aws_core<0.1.0",
    "smithy_aws_event_stream<0.1.0",
    "smithy_core<0.1.0",
    "smithy_http[awscrt]<0.1.0",
    "smithy_json<0.1.0"
]

---

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

[SamRemis]

To document a conversation we had on slack:

We decided against the alternate option (requiring the dependencies directly) since it's odd to add a direct dependency requirement on something we will depend on transitively.

It would make it much more difficult to reason about why a dependency is needed, and when it's safe to remove. Depending directly on a package because a dependency needs it creates confusion about ownership and purpose - if the transitive dependency changes its requirements or is removed entirely, we'd be left with direct dependencies that serve no clear purpose in our codebase. This approach also makes dependency management more complex, as we'd need to track both our actual needs and the needs of our dependencies, potentially leading to version conflicts or unnecessary bloat.

[jonathan343]

Note: In this repo, all our dependencies on smithy-* packages are unbounded. I think this is wrong and we should at least add upper bounds, however, I think that should be done in a separate PR to provide consistency.

Example:

json = [
    "smithy-json<=0.1.0"
]

[JordonPhillips]

I think that's a holdover from the previous build tool we were using which handled injecting versions.

[jonathan343]

Interesting, I didn't know that was possible. Do you know that tool that was? I can look into if uv supports that feature.