Closed endgame closed 1 year ago
This PR also changes how overrides are threaded to the defaultService
in bindings, so if you use a non-S3 object store (@ivb-supercede @tanyabouman @kfigiela) I would love to hear that it's still working for you.
Looking at the generated branch, lenses are still prefixed by their type, is that intended?
E.g. putObject_contentType :: Lens.Lens' PutObject (Prelude.Maybe Prelude.Text)
Yes, absolutely. This PR only touches amazonka-core
and amazonka
, and there are no plans to change those generated lenses.
But also: should we provide lenses for the un-prefixed records in that style, for consistency with the generated service bindings?
We avoid lenses in the code base that we use Amazonka in, so I don't feel strongly about it. But I'd prefer as much consistency as possible between amazonka-core
and other packages.
I have rearranged some module names so that Amazonka.Lens
can provide optics for all of amazonka
and amazonka-core
.
This PR also changes how overrides are threaded to the defaultService in bindings, so if you use a non-S3 object store (@ivb-supercede @tanyabouman @kfigiela) I would love to hear that it's still working for you.
Works fine in my testing, overriding the addressing style functions as expected.
Question for discussion: Should we provide van Laarhoven lenses for these records, like we do with the generated records in bindings?
Please. Unprefixed record fields are a bit of an importer's nightmare, and our codebase also leans heavily on Amazonka lenses.
Please. Unprefixed record fields are a bit of an importer's nightmare, and our codebase also leans heavily on Amazonka lenses.
These are in the PR as of a few hours ago, but I'm curious: have you tried generic-lens
or similar? That's what I normally use when writing code that uses amazonka.
have you tried generic-lens or similar? That's what I normally use when writing code that uses amazonka.
We use these rarely, but Generic
is bad for compile times, and I prefer to avoid it. If I want lenses without depending on lens
, I normally reach for microlens
instead.
The lenses already in this PR are great, I relied on them to migrate our existing code when testing the integration with our non-S3 store.
A couple of other bikeshedding questions, and then I'll probably merge this unless I hear objections:
S3AddressingStyle
prefix from the different addressing styles? I'm thinking "keep it", because we don't have tools to deal with ambiguity in case something else wants to call itself Auto
Generic
instance added?I would love to hear that it's still working for you.
Works for us. Thanks!
Remove all leading underscores and record field prefixes from records in
amazonka-core
andamazonka
. This is a big step towards removing the explicitlens
dependency (though we'll leave that until 2.1); instead, people should look to using record updates,generic-lens
/generic-optics
or (in GHC >=9.2)-XOverloadedRecordDot
for working with these fields.Other breaking changes: some functions were renamed/removed for consistency or to avoid name clashes:
Amazonka.Env.envAuthMaybe
->Amazonka.authMaybe
(and its re-export fromAmazonka
)Amazonka.Env.configure
->Amazonka.Env.configureService
(and its re-export fromAmazonka
)Amazonka.Env.override
->Amazonka.Env.overrideService
(and its re-export fromAmazonka
)Amazonka.Env.timeout
->Amazonka.Env.globalTimeout
(and its re-export fromAmazonka
)Amazonka.Env.within
: removed; it was merely a record updateAmazonka.Body._Body
: removed.Question for discussion: Should we provide van Laarhoven lenses for these records, like we do with the generated records in bindings? I see no problem with doing this; we can eventually go to a
profunctors
dependency and provide VL optics without too much trouble, though the few optics which usefiltered
will need a bit of thought.Also, since we're going to have to regenerate everything, I bumped
botocore
and configured all services that generated cleanly. A full regeneration is available at branchno-record-prefixes-gen
.Since this touches a bunch of signing code, I would appreciate reports from other people who have a chance to test this branch. Reports from people using presigning are especially welcome.
Closes #778 Fixes #752