search

JuliaCloud / AWS.jl

Julia interface to AWS
MIT License
160 stars 62 forks source link

Choose a canonical names for services #462

Open omus opened 3 years ago

omus commented 3 years ago

Right now @service supports allowing the user to define the casing used for the module name:

https://github.com/JuliaCloud/AWS.jl/blob/ca6b5509365d89e1878c770050b9d168402f7b0a/src/AWS.jl#L113-L116

If we implement #435 we should probably choose a single canonical spelling for each service instead of having the user be able to specify their own.

I think going with the standard Julia module naming convention is the correct approach which would result in:

ServiceId Proposed Module Name Current Module Name
S3 S3 s3
Secrets Manager SecretsManager secrets_manager
ACM PCA ACMPCA acm_pca
omus commented 3 years ago

Proposal for an backwards compatible implementation:

  1. When generating the high-level API file names keep the casing as defined by the ServiceId and keep the whitespace.
  2. Generate a mapping of lowercase service names to the high-level API file name that have entries using underscore or no space separator (e.g. "secretsmanager" => "Secrets Manager.jl", "secrets_manager" => "Secrets Manager.jl")
  3. When using @service lower case the specified module name and use the mapping to determine the service file name.
  4. If the module name passed into @service (prior to lower casing) does not match the service name (the service file name with spaces and the extension removed) then emit a deprecation warning

This should keep the current behaviour and also allow the use of the new proposed module names