With this commit, I have copied a significant amount of package
manager code from zig 0.11 that was not included in the standard
library. This code is in Package.zig, and was augmented/adjusted
to handle the use case of arbitrary data files rather than the
specialized zig project use case of the package manager. It
arguably should be in a seperate repo, but we can move this later
if needed.
This fixes main compile issues. Problems that remain:
* json is borked for objects with key/value keys that need to be coerced
* currently all request structures need an http_query declaration, and this may be a hard requirement
* need to revisit all the places where we are reading http response bodies
* there are 35 compile errors that do not have reference traces and will take a while to track down
This also includes a small change to force output of mappings even if empty
New zig correctly detects that without any field, we end up trying to use
a constant that does not exist (this is in the generated code)
This commit adds a new interface that is capable of runtime
use. By calling Request(action).call(request, options), the request
object can now be built at runtime. This change also moves the client
object into the options structure. It also moves the metaInfo generated
function to a type-based function rather than requiring an instance for
binding.
This provides initial implementation with some basic calls
working. Only GET requests have been verified so far.
Http header support missing. POST/PUT might work, but
have not been tested. Currently the demo tests are
failing due to a response deserialization issue that
is still being debugged
This will use the actual structure name or the override
from the trait as needed. Return value support
is also enabled in the code generation but not in
aws.zig. The current fuzzy checks should get most
of the way there though
Instead we will rely here on the implicit struct provided by the file
itself. This means that when the service_manifest.zig import is
assigned, we don't end up with a construct like "manifest.sts.sts" to
get to the sts service. This simplifies greatly the way that
servicemodel.zig needs to behave.
One down side, however, is that the structure does not seem
accessible with the current zig language, making metaInfo unable
to access itself as it did before. Or maybe it can, I just can't find
it. So, this change also adds a new "service_metadata" public constant
with the same declarations being published at the file level, and
that is the new return from the metaInfo function. Our aws.zig
only really needs the action and that metadata, so we're ok with that
even if there is some duplication (we could codegen pointers over, and
maybe should to save a little bit of space).
