Make @service only define a module once

[ararslan]

Currently, @service defines a module every time it's called. That works fine but the downside is that you get module redefinition warnings if you happen to call @service again. The most plausible reason why one would want to redefine the module would be to enable/disable particular features in some region of code. To facilitate that use case while avoiding redefinition warnings, we can make @service check for an existing module, define one if it can't find one, and if it can then modify the feature set associated with the module in place. With this change, @service S3 (e.g.) effectively expands to:

if isdefined(Main, :S3)
    AWS.set_features!(S3.SERVICE_FEATURE_SET)
else
    module S3
        # contents
    end
end

The set_features! call uses the features specified in the macro call as keyword arguments. No arguments uses defaults. Notably this design requires that FeatureSet be made mutable, which seems fine IMO.

---

• To see the specific tasks where the Asana app for GitHub is being used, see below:
  • https://app.asana.com/0/0/1210547384307405

[quinnj]

LGTM

[omus]

Do you have a scenario in which you want to call @service multiple times for the same AWS service? Doing this within a package seems like an anti-pattern and I would be okay with only allowing a single call to @service S3 within a given module (the user must choose the feature flags they want and be consistent within that module).

The only reason I can think of to support multiple @service calls for the same AWS service would be on the REPL where you may want to experiment with different feature flags without restarting your Julia session.

[ararslan]

Doing this within a package seems like an anti-pattern

I agree that the case this facilitates, dynamically changing the features in use for a given service, seems like an anti-pattern within a package. I'd be surprised if anybody would actually do that. The non-interactive use case I could imagine would be for folks who like to include all of their dependency loading at the top of each file in a package that utilizes those dependencies. (Not particularly common but I have seen it.)

The only reason I can think of to support multiple @service calls for the same AWS service would be on the REPL where you may want to experiment with different feature flags without restarting your Julia session.

I would consider this the primary use case.

[omus]

I feel more comfortable with these changes after working on #720. I think I'll merge #720 first as that PR adds more extensive tests for @service

[omus]

Thanks for updating the PR. I'll do some local experimentation with this yet. I expect this will be merged by or on Monday

[omus]

I'm fine with this for supporting interactive usage but for package development modifying the global feature set for the @service module is dangerous as this is effectively modifying a global which changes the behaviour of all function calls using the service module.

I'm not seeing what problem this is solving beyond hiding a warning which can now be alternatively solved with using the import as syntax: @service STS as A use_response_type=true; @service STS as B use_response_type=false.

I see two options to move forward:

1. We document the limitations of using @service on the same module name.
2. We update the examples in @service to show how to use the same service with different feature sets enabled.

[omus]

I'm surprised that the containing testset captures this test.

[ararslan]

¯\_(ツ)_/¯

[ararslan]

I'm fine with this for supporting interactive usage but for package development modifying the global feature set for the @service module is dangerous as this is effectively modifying a global which changes the behaviour of all function calls using the service module.

💯 this should only ever be used interactively. Perhaps some strong wording should be added to the documentation to that effect.

I'm not seeing what problem this is solving beyond hiding a warning which can now be alternatively solved with using the import as syntax: @service STS as A use_response_type=true; @service STS as B use_response_type=false.

The annoyance is needing to assign a different name during interactive use. The situation is somewhat analogous to how before Julia 1.12 you couldn't redefine a type at the REPL, so you needed to use a different name if you modified the structure at all. Admittedly that case is a bit different since it was an error rather than a warning, but I see no reason not to make things in this case friendlier for interactive use.

[ararslan]

Suggested change

	julia> @service STS as SecurityTokenService # reset a feature to its default by calling `@service` again
	julia> @service STS as SecurityTokenService # for interactive use, call `@service` again to reset a feature to its default