New package: AwsC v1.0.0

[JuliaRegistrator]

• Registering package: AwsC
• Repository: https://github.com/JuliaServices/AwsC.jl
• Created by: @quinnj
• Version: v1.0.0
• Commit: 5aedad30ba06f8349c4e8b580a6a19824e5af8bc
• Reviewed by: @quinnj
• Reference: https://github.com/JuliaServices/AwsC.jl/commit/5aedad30ba06f8349c4e8b580a6a19824e5af8bc#commitcomment-139133199

[github-actions[bot]]

Your new package pull request does not meet the guidelines for auto-merging. Please make sure that you have read the General registry README and the AutoMerge guidelines. The following guidelines were not met:

• Name is not at least 5 characters long
• Package name similar to 1 existing package.
  1. Similar to AWS. Damerau-Levenshtein distance 1 between lowercased names is at or below cutoff of 1.

Note that the guidelines are only required for the pull request to be merged automatically. However, it is strongly recommended to follow them, since otherwise the pull request needs to be manually reviewed and merged by a human.

After you have fixed the AutoMerge issues, simply retrigger Registrator, which will automatically update this pull request. You do not need to change the version number in your Project.toml file (unless of course the AutoMerge issue is that you skipped a version number, in which case you should change the version number).

If you do not want to fix the AutoMerge issues, please post a comment explaining why you would like this pull request to be manually merged. Then, send a message to the #pkg-registration channel in the Julia Slack to ask for help. Include a link to this pull request.

Since you are registering a new package, please make sure that you have also read the package naming guidelines: https://pkgdocs.julialang.org/v1/creating-packages/#Package-naming-guidelines

---

If you want to prevent this pull request from being auto-merged, simply leave a comment. If you want to post a comment without blocking auto-merging, you must include the text [noblock] in your comment. You can edit blocking comments, adding [noblock] to them in order to unblock auto-merging.

[goerz]

Maybe AWSCCommon?

[quinnj]

Hmmmm......I really like how short and sweet it is. Maybe AwsCommon. I have a couple of packages coming like AwsIO, AwsHTTP, etc. Doing all caps AWS just feels like way too many caps for some of these names.

[goerz]

"Short" tends to be a quite problematic these days, and especially if you have to name a set of packages with a common prefix. We're getting pretty close to all the "good" short names being taken. So I would not make that a goal. In principle, AWS is also an acronym, so it would actually be better if it stays in caps. To avoid the "too many caps", I would consider a naming scheme like AWSToolsIO, AWSToolsHTTP, and then maybe AWSToolsC for this package. (Maybe there's a better word than "Tools", but you get the idea)

[goerz]

Although given your track record, I'd give you some leeway ;-)

If you really want AwsC, there's probably someone who can merge it. Likewise, AwsHTTP etc.

[quinnj]

Sorry I forgot about this. Let's ping @fredrikekre, @StefanKarpinski, @KristofferC, and @Octogonapus to get their opinions. Namely, I have a suite of packages I'd like to register, mirroring the aws-c-X set of C libraries (https://docs.aws.amazon.com/sdkref/latest/guide/common-runtime.html). Doing AWSCommon, AWSIO, AWSHTTP, AWSS3 all feel excessively capitalized, so I think my preference is to do AwsC, AwsIO, AwsHTTP, AwsS3. These aren't meant to necessarily be widely used public packages, but more as building blocks for higher-level interfaces (like replacing the internals of HTTP w/ AwsHTTP).

[quinnj]

(also thanks for the quick review/feedback @goerz!)

[Octogonapus]

Doing AWSCommon, AWSIO, AWSHTTP, AWSS3 all feel excessively capitalized, so I think my preference is to do AwsC, AwsIO, AwsHTTP, AwsS3.

I think it is not clear, especially for AwsS3, that these package names refer to generated C bindings and a little filler, and not something higher level. I'd want to adopt a naming scheme like AwsCrt* e.g. AwsCrtS3, AwsCrtIO, etc. Also I agree with the AwsCrt* scheme instead of the AwsC* scheme because some of the CRT packages do not have -c- in their names, e.g. aws-lc which could be registered as AwsCrtLC.

This package also mixes high and low level functionality. Some decisions are made for the user, like in this init function, which makes these packages less composable. For example, my AWSCRT work would not compose well with this package. It would be better if you registered the generated bindings as separate LibAwsCrt* packages (containing only bindings).

[github-actions[bot]]

This pull request has been inactive for 30 days and will be automatically closed 7 days from now. If this pull request should not be closed, please either (1) fix the AutoMerge issues and re-trigger Registrator, which will automatically update the pull request, or (2) post a comment explaining why you would like this pull request to be manually merged. [noblock]

[quinnj]

@Octogonapus and I have come up w/ a new plan outlined in this slack thread where we'll implement LibAwsCommon, LibAwsIO, LibAwsHTTP etc libraries.

This PR can be closed.

[StefanKarpinski]

Replying late, but LibAws prefix is a good approach 👍🏻