conda-forge / conda-forge/aws-sdk-cpp-feedstock

Benefit of output separation - bring back everything under aws-sdk-cpp?

Open
#821 6 comments 0 reactions 0 assignees View on GitHub
Dominant language
Batchfile
Stars
1
Forks
22
PR merge metrics
No merged PRs in 30d

Description

I'm wondering what gains we're getting from having

```
aws-c-auth
aws-c-cal
aws-c-common
aws-c-compression
aws-c-event-stream
aws-c-http
aws-c-io
aws-c-mqtt
aws-c-s3
aws-c-sdkutils
aws-checksums
aws-crt-cpp
s2n
```

all being migrated separately. It's generating a lot of churn, and I'm not sure what gain we get in return?

It might make sense to rather just implicitly migrate through this package?

W.r.t. to the costs that any benefits would need to offset (IMO) the very frequent migrations for all of the above packages. That alone creates a lot of maintenance on the pinning repo, but worse than that, they often logjam because one of the packages involved automerges a new version while another migration is still running, requiring manual intervention.

While the above migrations are mostly internal (i.e. don't cause rebuilds of packages outside of `aws-*`), and we finally reduced the number of "external" migrations due to `aws-sdk-cpp` in #662, there are still ways this amps up the maintenance elsewhere.

For example, I added `aws-crt-cpp` as a host-dep to arrow because the link check complained otherwise, which worked without too much hassle for some time, but now generated 3 migrations (times 4 maintenance branches) in a very short succession (https://github.com/conda-forge/arrow-cpp-feedstock/pull/1224, https://github.com/conda-forge/arrow-cpp-feedstock/pull/1229, https://github.com/conda-forge/arrow-cpp-feedstock/pull/1240)

CC @conda-forge/aws-sdk-cpp @conda-forge/core

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.