# packages

pkgId: 95846b3655c39451de4f281bd12c4e2c653f8eabff592b6e53b89af74518ec42
name: python-aws-cdk.aws-synthetics-alpha
arch: src
version: 2.101.1a0
epoch: 0
release: 1
summary: This module is deprecated. All constructs are now available under aws-cdk-lib/aws-synthetics
url: https://github.com/aws/aws-cdk
rpm_license: Apache-2.0
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-cdk.aws-synthetics-alpha-2.101.1a0-1.src.rpm
checksum_type: sha256
description:
  <!--END STABILITY BANNER-->
  All constructs moved to aws-cdk-lib/aws-synthetics.
  Amazon CloudWatch Synthetics allow you to monitor your application by generating **synthetic** traffic. The traffic is produced by a **canary**: a configurable script that runs on a schedule. You configure the canary script to follow the same routes and perform the same actions as a user, which allows you to continually verify your user experience even when you don't have any traffic on your applications.

  To illustrate how to use a canary, assume your application defines the following endpoint:
  ```console
  % curl "https://api.example.com/user/books/topbook/"
  The Hitchhikers Guide to the Galaxy
  ```
  The below code defines a canary that will hit the `books/topbook` endpoint every 5 minutes:
  ```python
  canary = synthetics.Canary(self, "MyCanary",
      schedule=synthetics.Schedule.rate(Duration.minutes(5)),
      test=synthetics.Test.custom(
          code=synthetics.Code.from_asset(path.join(__dirname, "canary")),
          handler="index.handler"
      ),
      runtime=synthetics.Runtime.SYNTHETICS_NODEJS_PUPPETEER_4_0,
      environment_variables={
          "stage": "prod"
      }
  )
  ```
  The following is an example of an `index.js` file which exports the `handler` function:
  ```js
  const synthetics = require('Synthetics');
  const log = require('SyntheticsLogger');
  const pageLoadBlueprint = async function () {
    // Configure the stage of the API using environment variables
    const url = `https://api.example.com/${process.env.stage}/user/books/topbook/`;
    const page = await synthetics.getPage();
    const response = await page.goto(url, { waitUntil: 'domcontentloaded', timeout: 30000 });
    // Wait for page to render. Increase or decrease wait time based on endpoint being monitored.
    await page.waitFor(15000);
    // This will take a screenshot that will be included in test output artifacts.
    await synthetics.takeScreenshot('loaded', 'loaded');
    const pageTitle = await page.title();
    log.info('Page title: ' + pageTitle);
    if (response.status() !== 200) {
      throw 'Failed to load page!';
    }
  };
  exports.handler = async () => {
    return await pageLoadBlueprint();
  };
  ```
  > **Note:** The function **must** be called `handler`.
  The canary will automatically produce a CloudWatch Dashboard:
  ![UI Screenshot](images/ui-screenshot.png)
  The Canary code will be executed in a lambda function created by Synthetics on your behalf. The Lambda function includes a custom [runtime](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries_Library.html) provided by Synthetics. The provided runtime includes a variety of handy tools such as [Puppeteer](https://www.npmjs.com/package/puppeteer-core) (for nodejs based one) and Chromium.
  To learn more about Synthetics capabilities, check out the [docs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html).

  You can specify the schedule on which a canary runs by providing a
  [`Schedule`](https://docs.aws.amazon.com/cdk/api/latest/docs/@aws-cdk_aws-synthetics.Schedule.html)
  object to the `schedule` property.
  Configure a run rate of up to 60 minutes with `Schedule.rate`:
  ```python
  schedule = synthetics.Schedule.rate(Duration.minutes(5))
  ```
  You can also specify a [cron expression](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries_cron.html) with `Schedule.cron`:
  ```python
  schedule = synthetics.Schedule.cron(
      hour="0,8,16"
  )
  ```
  If you want the canary to run just once upon deployment, you can use `Schedule.once()`.

  When you delete a lambda, the following underlying resources are isolated in your AWS account:
  * Lambda Function that runs your canary script
  * S3 Bucket for artifact storage
  * IAM roles and policies
  * Log Groups in CloudWatch Logs.
  To learn more about these underlying resources, see
  [Synthetics Canaries Deletion](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/synthetics_canaries_deletion.html).
  In the CDK, you can configure your canary to delete the underlying lambda function when the canary is deleted.
  This can be provisioned by setting `cleanup: Cleanup.LAMBDA`. Note that this
  will create a custom resource under the hood that takes care of the lambda deletion for you.
  ```python
  canary = synthetics.Canary(self, "Canary",
      test=synthetics.Test.custom(
          handler="index.handler",
          code=synthetics.Code.from_inline("/* Synthetics handler code")
      ),
      cleanup=synthetics.Cleanup.LAMBDA,
      runtime=synthetics.Runtime.SYNTHETICS_NODEJS_PUPPETEER_4_0
  )
  ```
  > Note: To properly clean up your canary on deletion, you still have to manually delete other resources
  > like S3 buckets and CloudWatch logs.

  To configure the script the canary executes, use the `test` property. The `test` property accepts a `Test` instance that can be initialized by the `Test` class static methods. Currently, the only implemented method is `Test.custom()`, which allows you to bring your own code. In the future, other methods will be added. `Test.custom()` accepts `code` and `handler` properties -- both are required by Synthetics to create a lambda function on your behalf.
  The `synthetics.Code` class exposes static methods to bundle your code artifacts:
  * `code.fromInline(code)` - specify an inline script.
  * `code.fromAsset(path)` - specify a .zip file or a directory in the local filesystem which will be zipped and uploaded to S3 on deployment. See the above Note for directory structure.
  * `code.fromBucket(bucket, key[, objectVersion])` - specify an S3 object that contains the .zip file of your runtime code. See the above Note for directory structure.
  Using the `Code` class static initializers:
  ```python

  import aws_cdk.aws_s3 as s3

  synthetics.Canary(self, "Inline Canary",
      test=synthetics.Test.custom(
          code=synthetics.Code.from_inline("/* Synthetics handler code */"),
          handler="index.handler"
      ),
      runtime=synthetics.Runtime.SYNTHETICS_NODEJS_PUPPETEER_4_0
  )

  synthetics.Canary(self, "Asset Canary",
      test=synthetics.Test.custom(
          code=synthetics.Code.from_asset(path.join(__dirname, "canary")),
          handler="index.handler"
      ),
      runtime=synthetics.Runtime.SYNTHETICS_NODEJS_PUPPETEER_4_0
  )
  bucket = s3.Bucket(self, "Code Bucket")
  synthetics.Canary(self, "Bucket Canary",
      test=synthetics.Test.custom(
          code=synthetics.Code.from_bucket(bucket, "canary.zip"),
          handler="index.handler"
      ),
      runtime=synthetics.Runtime.SYNTHETICS_NODEJS_PUPPETEER_4_0
  )
  ```
  > **Note:** Synthetics have a specified folder structure for canaries. For Node scripts supplied via `code.fromAsset()` or `code.fromBucket()`, the canary resource requires the following folder structure:
  >
  > ```plaintext
  > canary/
  > ├── nodejs/
  >    ├── node_modules/
  >         ├── <filename>.js
  > ```
  >
  > For Python scripts supplied via `code.fromAsset()` or `code.fromBucket()`, the canary resource requires the following folder structure:
  >
  > ```plaintext
  > canary/
  > ├── python/
  >     ├── <filename>.py
  > ```
  >
  > See Synthetics [docs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries_WritingCanary.html).

  You can specify what [VPC a canary executes in](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries_VPC.html).
  This can allow for monitoring services that may be internal to a specific VPC. To place a canary within a VPC, you can specify the `vpc` property with the desired `VPC` to place then canary in.
  This will automatically attach the appropriate IAM permissions to attach to the VPC. This will also create a Security Group and attach to the default subnets for the VPC unless specified via `vpcSubnets` and `securityGroups`.
  ```python
  import aws_cdk.aws_ec2 as ec2

  synthetics.Canary(self, "Vpc Canary",
      test=synthetics.Test.custom(
          code=synthetics.Code.from_asset(path.join(__dirname, "canary")),
          handler="index.handler"
      ),
      runtime=synthetics.Runtime.SYNTHETICS_NODEJS_PUPPETEER_4_0,
      vpc=vpc
  )
  ```
  > **Note:** By default, the Synthetics runtime needs access to the S3 and CloudWatch APIs, which will fail in a private subnet without internet access enabled (e.g. an isolated subnnet).
  >
  > Ensure that the Canary is placed in a VPC either with internet connectivity or with VPC Endpoints for S3 and CloudWatch enabled and configured.
  >
  > See [Synthetics VPC docs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries_VPC.html).

  You can configure a CloudWatch Alarm on a canary metric. Metrics are emitted by CloudWatch automatically and can be accessed by the following APIs:
  * `canary.metricSuccessPercent()` - percentage of successful canary runs over a given time
  * `canary.metricDuration()` - how much time each canary run takes, in seconds.
  * `canary.metricFailed()` - number of failed canary runs over a given time
  Create an alarm that tracks the canary metric:
  ```python
  import aws_cdk.aws_cloudwatch as cloudwatch

  cloudwatch.Alarm(self, "CanaryAlarm",
      metric=canary.metric_success_percent(),
      evaluation_periods=2,
      threshold=90,
      comparison_operator=cloudwatch.ComparisonOperator.LESS_THAN_THRESHOLD
  )
  ```

  You can pass an S3 bucket to store artifacts from canary runs. If you do not,
  one will be auto-generated when the canary is created. You may add
  [lifecycle rules](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html)
  to the auto-generated bucket.
  ```python
  canary = synthetics.Canary(self, "MyCanary",
      schedule=synthetics.Schedule.rate(Duration.minutes(5)),
      test=synthetics.Test.custom(
          code=synthetics.Code.from_asset(path.join(__dirname, "canary")),
          handler="index.handler"
      ),
      runtime=synthetics.Runtime.SYNTHETICS_NODEJS_PUPPETEER_4_0,
      artifacts_bucket_lifecycle_rules=[LifecycleRule(
          expiration=Duration.days(30)
      )]
  )
  ```


pkgId: 72961c84d0c511368f95a21a2317ab45b687ab96f6929109c0961a3e73808317
name: python-aws-cdk.cli-lib-alpha
arch: src
version: 2.163.1a0
epoch: 0
release: 1
summary: AWS CDK Programmatic CLI library
url: https://github.com/aws/aws-cdk
rpm_license: Apache-2.0
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-cdk.cli-lib-alpha-2.163.1a0-1.src.rpm
checksum_type: sha256
description:
  <!--END STABILITY BANNER-->

  This package is highly experimental. Expect frequent API changes and incomplete features.
  Known issues include:
  * **JavaScript/TypeScript only**\
    The jsii packages are currently not in a working state.
  * **No useful return values**\
    All output is currently printed to stdout/stderr
  * **Missing or Broken options**\
    Some CLI options might not be available in this package or broken

  Provides a library to interact with the AWS CDK CLI programmatically from jsii supported languages.
  Currently the package includes implementations for:
  * `cdk deploy`
  * `cdk synth`
  * `cdk bootstrap`
  * `cdk destroy`
  * `cdk list`


  Obtain an `AwsCdkCli` class from an AWS CDK app directory (containing a `cdk.json` file):
  ```python
  cli = AwsCdkCli.from_cdk_app_directory("/path/to/cdk/app")
  ```

  You can also create `AwsCdkCli` from a class implementing `ICloudAssemblyDirectoryProducer`.
  AWS CDK apps might need to be synthesized multiple times with additional context values before they are ready.
  The `produce()` method of the `ICloudAssemblyDirectoryProducer` interface provides this multi-pass ability.
  It is invoked with the context values of the current iteration and should use these values to synthesize a Cloud Assembly.
  The return value is the path to the assembly directory.
  A basic implementation would look like this:
  ```python
  @jsii.implements(ICloudAssemblyDirectoryProducer)
  class MyProducer:
      def produce(self, context):
          app = cdk.App(context=context)
          stack = cdk.Stack(app)
          return app.synth().directory
  ```
  For all features (e.g. lookups) to work correctly, `cdk.App()` must be instantiated with the received `context` values.
  Since it is not possible to update the context of an app, it must be created as part of the `produce()` method.
  The producer can than be used like this:
  ```python
  cli = AwsCdkCli.from_cloud_assembly_directory_producer(MyProducer())
  ```


  ```python

  cli.list()
  ```

  ```python

  cli.synth(
      stacks=["MyTestStack"]
  )
  ```

  ```python

  cli.bootstrap()
  ```

  ```python

  cli.deploy(
      stacks=["MyTestStack"]
  )
  ```

  ```python

  cli.destroy(
      stacks=["MyTestStack"]
  )
  ```


pkgId: f4362aba253cbad49c36725940da197d5c52b459bb4efcc2957a67e488b286db
name: python-aws-cdk.cloud-assembly-schema
arch: src
version: 38.0.1
epoch: 0
release: 1
summary: Cloud Assembly Schema
url: https://github.com/cdklabs/cloud-assembly-schema
rpm_license: Apache-2.0
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-cdk.cloud-assembly-schema-38.0.1-1.src.rpm
checksum_type: sha256
description:
  This module is part of the [AWS Cloud Development Kit](https://github.com/aws/aws-cdk) project.



  The *Cloud Assembly* is the output of the synthesis operation. It is produced as part of the
  [`cdk synth`](https://github.com/aws/aws-cdk/tree/main/packages/aws-cdk#cdk-synthesize)
  command, or the [`app.synth()`](https://github.com/aws/aws-cdk/blob/main/packages/@aws-cdk/core/lib/app.ts#L135) method invocation.

  Its essentially a set of files and directories, one of which is the `manifest.json` file. It defines the set of instructions that are
  needed in order to deploy the assembly directory.

  > For example, when `cdk deploy` is executed, the CLI reads this file and performs its instructions:
  >
  > * Build container images.
  > * Upload assets.
  > * Deploy CloudFormation templates.

  Therefore, the assembly is how the CDK class library and CDK CLI (or any other consumer) communicate. To ensure compatibility
  between the assembly and its consumers, we treat the manifest file as a well defined, versioned schema.



  This module contains the typescript structs that comprise the `manifest.json` file, as well as the
  generated [*json-schema*](./schema/cloud-assembly.schema.json).



  The schema version is specified my the major version of the package release. It follows semantic versioning, but with a small twist.

  When we add instructions to the assembly, they are reflected in the manifest file and the *json-schema* accordingly.
  Every such instruction, is crucial for ensuring the correct deployment behavior. This means that to properly deploy a cloud assembly,
  consumers must be aware of every such instruction modification.

  For this reason, every change to the schema, even though it might not strictly break validation of the *json-schema* format,
  is considered `major` version bump. All changes that do not impact the schema are considered a `minor` version bump.



  If you'd like to consume the [schema file](./schema/cloud-assembly.schema.json) in order to do validations on `manifest.json` files,
  simply download it from this repo and run it against standard *json-schema* validators, such as [jsonschema](https://www.npmjs.com/package/jsonschema).

  Consumers must take into account the `major` version of the schema they are consuming. They should reject cloud assemblies
  with a `major` version that is higher than what they expect. While schema validation might pass on such assemblies, the deployment integrity
  cannot be guaranteed because some instructions will be ignored.

  > For example, if your consumer was built when the schema version was 2.0.0, you should reject deploying cloud assemblies with a
  > manifest version of 3.0.0.



  See [Contribution Guide](./CONTRIBUTING.md)


pkgId: 7e64ad7ad2f0e9e94237a9c55113be641681cb2f6e2f4c8ba64925b511bcf6eb
name: python-aws-cdk.cx-api
arch: src
version: 2.159.0
epoch: 0
release: 1
summary: Cloud executable protocol
url: https://github.com/aws/aws-cdk
rpm_license: Apache-2.0
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-cdk.cx-api-2.159.0-1.src.rpm
checksum_type: sha256
description:
  This module is part of the [AWS Cloud Development Kit](https://github.com/aws/aws-cdk) project.



  * `@aws-cdk/aws-s3:createDefaultLoggingPolicy`

  Enable this feature flag to create an S3 bucket policy by default in cases where
  an AWS service would automatically create the Policy if one does not exist.

  For example, in order to send VPC flow logs to an S3 bucket, there is a specific Bucket Policy
  that needs to be attached to the bucket. If you create the bucket without a policy and then add the
  bucket as the flow log destination, the service will automatically create the bucket policy with the
  necessary permissions. If you were to then try and add your own bucket policy CloudFormation will throw
  and error indicating that a bucket policy already exists.

  In cases where we know what the required policy is we can go ahead and create the policy so we can
  remain in control of it.

  https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-and-resource-policy.html#AWS-logs-infrastructure-S3

  *cdk.json*

  ```json
  {
    "context": {
      "@aws-cdk/aws-s3:createDefaultLoggingPolicy": true
    }
  }
  ```

  * `@aws-cdk/aws-sns-subscriptions:restrictSqsDescryption`

  Enable this feature flag to restrict the decryption of a SQS queue, which is subscribed to a SNS topic, to
  only the topic which it is subscribed to and not the whole SNS service of an account.

  Previously the decryption was only restricted to the SNS service principal. To make the SQS subscription more
  secure, it is a good practice to restrict the decryption further and only allow the connected SNS topic to decryption
  the subscribed queue.

  *cdk.json*

  ```json
  {
    "context": {
      "@aws-cdk/aws-sns-subscriptions:restrictSqsDescryption": true
    }
  }
  ```

  * @aws-cdk/aws-apigateway:disableCloudWatchRole

  Enable this feature flag to change the default behavior for aws-apigateway.RestApi and aws-apigateway.SpecRestApi
  to *not* create a CloudWatch role and Account. There is only a single ApiGateway account per AWS
  environment which means that each time you create a RestApi in your account the ApiGateway account
  is overwritten. If at some point the newest RestApi is deleted, the ApiGateway Account and CloudWatch
  role will also be deleted, breaking any existing ApiGateways that were depending on them.

  When this flag is enabled you should either create the ApiGateway account and CloudWatch role
  separately *or* only enable the cloudWatchRole on a single RestApi.

  *cdk.json*

  ```json
  {
    "context": {
      "@aws-cdk/aws-apigateway:disableCloudWatchRole": true
    }
  }
  ```

  * `@aws-cdk/core:enablePartitionLiterals`

  Enable this feature flag to have `Stack.partition` return a literal string for a stack's partition
  when the stack has a known region configured.  If the region is undefined, or set to an unknown value, the
  `Stack.partition` will be the CloudFormation intrinsic value `AWS::Partition`.  Without this feature flag,
  `Stack.partition` always returns the CloudFormation intrinsic value `AWS::Partition`.

  This feature will often simplify ARN strings in CDK generated templates, for example:

  ```yaml
   Principal:
     AWS:
       Fn::Join:
         - ""
         - - "arn:"
           - Ref: AWS::Partition
           - :iam::123456789876:root
  ```

  becomes:

  ```yaml
   Principal:
     AWS: "arn:aws:iam::123456789876:root"
  ```

  * `@aws-cdk/aws-ecs:disableExplicitDeploymentControllerForCircuitBreaker`

  Enable this feature flag to avoid setting the "ECS" deployment controller when adding a circuit breaker to an
  ECS Service, as this will trigger a full replacement which fails to deploy when using set service names.
  This does not change any behaviour as the default deployment controller when it is not defined is ECS.

  *cdk.json*

  ```json
  {
    "context": {
      "@aws-cdk/aws-ecs:disableExplicitDeploymentControllerForCircuitBreaker": true
    }
  }
  ```

  * `@aws-cdk/aws-s3:serverAccessLogsUseBucketPolicy`

  Enable this feature flag to use S3 Bucket Policy for granting permission fo Server Access Logging
  rather than using the canned `LogDeliveryWrite` ACL. ACLs do not work when Object Ownership is
  enabled on the bucket.

  This flag uses a Bucket Policy statement to allow Server Access Log delivery, following best
  practices for S3.

  https://docs.aws.amazon.com/AmazonS3/latest/userguide/enable-server-access-logging.html

  ```json
  {
    "context": {
      "@aws-cdk/aws-s3:serverAccessLogsUseBucketPolicy": true
    }
  }
  ```

  * `@aws-cdk/aws-rds:databaseProxyUniqueResourceName`

  Enable this feature flag to use unique resource names for each `DatabaseProxy`.

  Previously, the default behavior for `DatabaseProxy` was to use `id` of the constructor for `dbProxyName`.
  In this case, users couldn't deploy `DatabaseProxy`s that have the same `id` in the same region.

  This is a feature flag as the old behavior was technically incorrect, but users may have come to depend on it.

  ```json
  {
    "context": {
      "@aws-cdk/aws-rds:databaseProxyUniqueResourceName": true
    }
  }
  ```

  * `@aws-cdk/aws-redshift:columnId`

  Enable this feature flag to allow the CDK to track changes in Redshift columns through their `id` attribute. This is a breaking change, as the `name` attribute was currently being used to track changes to Redshift columns.

  Enabling this feature flag comes at a risk for existing Redshift columns, as the `name` attribute of a redshift column was currently being used. Therefore, to change a Redshift columns' `name` will essentially create a new column and delete the old one. This will cause data loss. If you choose to enable this flag, ensure that upon intial deployment (the first deployment after setting this feature flag), the `name` attribute of every column is not changed. After the intial deployment, you can freely change the `name` attribute of a column.

  *cdk.json*

  ```json
  {
    "context": {
      "@aws-cdk/aws-redshift:columnId": true
    }
  }
  ```

  * `@aws-cdk/aws-stepfunctions-tasks:enableEmrServicePolicyV2`

  Enable this feature flag to use the `AmazonEMRServicePolicy_v2` managed policies for the EMR service role.

  This is a feature flag as the old behavior will be deprecated, but some resources may require manual
  intervention since they might not have the appropriate tags propagated automatically.

  https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-managed-iam-policies.html

  *cdk.json*

  ```json
  {
    "context": {
      "@aws-cdk/aws-stepfunctions-tasks:enableEmrServicePolicyV2": true
    }
  }
  ```

  * `@aws-cdk/core:includePrefixInUniqueNameGeneration`

  Enable this feature flag to include the stack's prefixes to the name generation process.

  Not doing so can cause the name of stack to exceed 128 characters:

  * The name generation ensures it doesn't exceed 128 characters
  * Without this feature flag, the prefix is prepended to the generated name, which result can exceed 128 characters

  This is a feature flag as it changes the name generated for stacks. Any CDK application deployed prior this fix will
  most likely be generated with a new name, causing the stack to be recreated with the new name, and then deleting the old one.
  For applications running on production environments this can be unmanageable.

  *cdk.json*

  ```json
  {
    "context": {
      "@aws-cdk/core:includePrefixInUniqueNameGeneration": true
    }
  }
  ```

  * `@aws-cdk/aws-lambda-nodejs:useLatestRuntimeVersion`

  Enable this feature flag to automatically use the latest available NodeJS version in the aws-lambda-nodejse.Function construct.

  This allows creation of new functions using a version that will automatically stay up to date without breaking bundling of existing functions that externalize packages included in their environemnt such as `aws-sdk`.

  Functions defined previously will continue to function correctly as long as they pass an explicit runtime version, or do not exclude packages during bundling.

  *cdk.json*

  ```json
  {
    "context": {
      "@aws-cdk/aws-lambda-nodejs:useLatestRuntimeVersion": true
    }
  }
  ```

  * `@aws-cdk/aws-codepipeline-actions:useNewDefaultBranchForCodeCommitSource`

  Enable this feature flag to update the default branch for CodeCommit source actions to `main`.

  Previously, the default branch for CodeCommit source actions was set to `master`.
  However, this convention is no longer supported, and repositories created after March 2021 now have `main` as
  their default branch.

  *cdk.json*

  ```json
  {
    "context": {
      "@aws-cdk/aws-codepipeline-actions:useNewDefaultBranchForCodeCommitSource": true
    }
  }
  ```

  * `@aws-cdk/aws-cloudwatch-actions:changeLambdaPermissionLogicalIdForLambdaAction`

  Enable this feature flag to change the logical ID of the `LambdaPermission` for the `LambdaAction` to include an alarm ID.

  Previously, only one alarm with the `LambdaAction` could be created per Lambda.
  This flag allows multiple alarms with the `LambdaAction` for the same Lambda to be created.

  *cdk.json*

  ```json
  {
    "context": {
      "@aws-cdk/aws-cloudwatch-actions:changeLambdaPermissionLogicalIdForLambdaAction": true
    }
  }
  ```

  * `@aws-cdk/aws-codepipeline:crossAccountKeysDefaultValueToFalse`

  Enables Pipeline to set the default value for `crossAccountKeys` to false.

  When this feature flag is enabled, and the `crossAccountKeys` property is not provided in a `Pipeline`
  construct, the construct automatically defaults the value of this property to false.

  *cdk.json*

  ```json
  {
    "context": {
      "@aws-cdk/aws-codepipeline:crossAccountKeysDefaultValueToFalse": true
    }
  }
  ```

  * `@aws-cdk/aws-codepipeline:defaultPipelineTypeToV2`

  Enables Pipeline to set the default pipeline type to V2.

  When this feature flag is enabled, and the `pipelineType` property is not provided in a `Pipeline`
  construct, the construct automatically defaults the value of this property to `PipelineType.V2`.

  *cdk.json*

  ```json
  {
    "context": {
      "@aws-cdk/aws-codepipeline:defaultPipelineTypeToV2": true
    }
  }
  ```

  * `@aws-cdk/aws-kms:reduceCrossAccountRegionPolicyScope`

  Reduce resource scope of the IAM Policy created from KMS key grant to granting key only.

  When this feature flag is enabled and calling KMS key grant method, the created IAM policy will reduce the resource scope from
  '*' to this specific granting KMS key.

  *cdk.json*

  ```json
  {
    "context": {
      "@aws-cdk/aws-kms:reduceCrossAccountRegionPolicyScope": true
    }
  }
  ```

  * `@aws-cdk/aws-eks:nodegroupNameAttribute`

  When enabled, nodegroupName attribute of the provisioned EKS NodeGroup will not have the cluster name prefix.

  When this feature flag is enabled, the nodegroupName attribute will be exactly the name of the nodegroup
  without any prefix.

  *cdk.json*

  ```json
  {
    "context": {
      "@aws-cdk/aws-eks:nodegroupNameAttribute": true
    }
  }
  ```

  * `@aws-cdk/aws-ec2:ebsDefaultGp3Volume`

  When enabled, the default volume type of the EBS volume will be GP3.

  When this featuer flag is enabled, the default volume type of the EBS volume will be `EbsDeviceVolumeType.GENERAL_PURPOSE_SSD_GP3`

  *cdk.json*

  ```json
  {
    "context": {
      "@aws-cdk/aws-ec2:ebsDefaultGp3Volume": true
    }
  }
  ```

  * `@aws-cdk/aws-ecs:removeDefaultDeploymentAlarm`

  When enabled, remove default deployment alarm settings.

  When this featuer flag is enabled, remove the default deployment alarm settings when creating a AWS ECS service.

  *cdk.json*

  ```json
  {
    "context": {
      "@aws-cdk/aws-ec2:ebsDefaultGp3Volume": true
    }
  }
  ```

  * `@aws-cdk/aws-stepfunctions-tasks:ecsReduceRunTaskPermissions`

  When enabled, IAM Policy created to run tasks won't include the task definition ARN, only the revision ARN.

  When this feature flag is enabled, the IAM Policy created to run tasks won't include the task definition ARN, only the revision ARN.
  The revision ARN is more specific than the task definition ARN. See https://docs.aws.amazon.com/step-functions/latest/dg/ecs-iam.html
  for more details.

  *cdk.json*

  ```json
  {
    "context": {
      "@aws-cdk/aws-stepfunctions-tasks:ecsReduceRunTaskPermissions": true
    }
  }
  ```

  * `@aws-cdk/aws-stepfunctions-taks:useNewS3UriParametersForBedrockInvokeModelTask`

  When enabled, use new props for S3 URI under `input` and `output` fields in task definition of state machine for bedrock invoke model.

  When this feature flag is enabled, use newly introduced props `s3InputUri` and `s3OutputUri` to populate S3 uri under input and output fields in state machine task definition for Bedrock invoke model.

  *cdk.json*

  ```json
  {
    "context": {
      "@aws-cdk/aws-stepfunctions-tasks:useNewS3UriParametersForBedrockInvokeModelTask": true
    }
  }
  ```

  * `@aws-cdk/aws-ecs:reduceEc2FargateCloudWatchPermissions`

  Currently, we will automatically add a number of cloudwatch permissions to the task role when no cloudwatch log group is
  specified as logConfiguration and it will grant 'Resources': ['*'] to the task role.

  When this feature flag is enabled, we will only grant the necessary permissions when users specify cloudwatch log group.

  *cdk.json*

  ```json
  {
    "context": {
      "@aws-cdk/aws-ecs:reduceEc2FargateCloudWatchPermissions": true
    }
  }
  ```


pkgId: 943e7799a62433789931b7f1350aecbd1952474d4bb9539d29b16169df5a7abc
name: python-aws-cdk.cx-api
arch: src
version: 2.161.1
epoch: 0
release: 1
summary: Cloud executable protocol
url: https://github.com/aws/aws-cdk
rpm_license: Apache-2.0
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-cdk.cx-api-2.161.1-1.src.rpm
checksum_type: sha256
description:
  This module is part of the [AWS Cloud Development Kit](https://github.com/aws/aws-cdk) project.



  * `@aws-cdk/aws-s3:createDefaultLoggingPolicy`

  Enable this feature flag to create an S3 bucket policy by default in cases where
  an AWS service would automatically create the Policy if one does not exist.

  For example, in order to send VPC flow logs to an S3 bucket, there is a specific Bucket Policy
  that needs to be attached to the bucket. If you create the bucket without a policy and then add the
  bucket as the flow log destination, the service will automatically create the bucket policy with the
  necessary permissions. If you were to then try and add your own bucket policy CloudFormation will throw
  and error indicating that a bucket policy already exists.

  In cases where we know what the required policy is we can go ahead and create the policy so we can
  remain in control of it.

  https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-and-resource-policy.html#AWS-logs-infrastructure-S3

  *cdk.json*

  ```json
  {
    "context": {
      "@aws-cdk/aws-s3:createDefaultLoggingPolicy": true
    }
  }
  ```

  * `@aws-cdk/aws-sns-subscriptions:restrictSqsDescryption`

  Enable this feature flag to restrict the decryption of a SQS queue, which is subscribed to a SNS topic, to
  only the topic which it is subscribed to and not the whole SNS service of an account.

  Previously the decryption was only restricted to the SNS service principal. To make the SQS subscription more
  secure, it is a good practice to restrict the decryption further and only allow the connected SNS topic to decryption
  the subscribed queue.

  *cdk.json*

  ```json
  {
    "context": {
      "@aws-cdk/aws-sns-subscriptions:restrictSqsDescryption": true
    }
  }
  ```

  * @aws-cdk/aws-apigateway:disableCloudWatchRole

  Enable this feature flag to change the default behavior for aws-apigateway.RestApi and aws-apigateway.SpecRestApi
  to *not* create a CloudWatch role and Account. There is only a single ApiGateway account per AWS
  environment which means that each time you create a RestApi in your account the ApiGateway account
  is overwritten. If at some point the newest RestApi is deleted, the ApiGateway Account and CloudWatch
  role will also be deleted, breaking any existing ApiGateways that were depending on them.

  When this flag is enabled you should either create the ApiGateway account and CloudWatch role
  separately *or* only enable the cloudWatchRole on a single RestApi.

  *cdk.json*

  ```json
  {
    "context": {
      "@aws-cdk/aws-apigateway:disableCloudWatchRole": true
    }
  }
  ```

  * `@aws-cdk/core:enablePartitionLiterals`

  Enable this feature flag to have `Stack.partition` return a literal string for a stack's partition
  when the stack has a known region configured.  If the region is undefined, or set to an unknown value, the
  `Stack.partition` will be the CloudFormation intrinsic value `AWS::Partition`.  Without this feature flag,
  `Stack.partition` always returns the CloudFormation intrinsic value `AWS::Partition`.

  This feature will often simplify ARN strings in CDK generated templates, for example:

  ```yaml
   Principal:
     AWS:
       Fn::Join:
         - ""
         - - "arn:"
           - Ref: AWS::Partition
           - :iam::123456789876:root
  ```

  becomes:

  ```yaml
   Principal:
     AWS: "arn:aws:iam::123456789876:root"
  ```

  * `@aws-cdk/aws-ecs:disableExplicitDeploymentControllerForCircuitBreaker`

  Enable this feature flag to avoid setting the "ECS" deployment controller when adding a circuit breaker to an
  ECS Service, as this will trigger a full replacement which fails to deploy when using set service names.
  This does not change any behaviour as the default deployment controller when it is not defined is ECS.

  *cdk.json*

  ```json
  {
    "context": {
      "@aws-cdk/aws-ecs:disableExplicitDeploymentControllerForCircuitBreaker": true
    }
  }
  ```

  * `@aws-cdk/aws-s3:serverAccessLogsUseBucketPolicy`

  Enable this feature flag to use S3 Bucket Policy for granting permission fo Server Access Logging
  rather than using the canned `LogDeliveryWrite` ACL. ACLs do not work when Object Ownership is
  enabled on the bucket.

  This flag uses a Bucket Policy statement to allow Server Access Log delivery, following best
  practices for S3.

  https://docs.aws.amazon.com/AmazonS3/latest/userguide/enable-server-access-logging.html

  ```json
  {
    "context": {
      "@aws-cdk/aws-s3:serverAccessLogsUseBucketPolicy": true
    }
  }
  ```

  * `@aws-cdk/aws-rds:databaseProxyUniqueResourceName`

  Enable this feature flag to use unique resource names for each `DatabaseProxy`.

  Previously, the default behavior for `DatabaseProxy` was to use `id` of the constructor for `dbProxyName`.
  In this case, users couldn't deploy `DatabaseProxy`s that have the same `id` in the same region.

  This is a feature flag as the old behavior was technically incorrect, but users may have come to depend on it.

  ```json
  {
    "context": {
      "@aws-cdk/aws-rds:databaseProxyUniqueResourceName": true
    }
  }
  ```

  * `@aws-cdk/aws-redshift:columnId`

  Enable this feature flag to allow the CDK to track changes in Redshift columns through their `id` attribute. This is a breaking change, as the `name` attribute was currently being used to track changes to Redshift columns.

  Enabling this feature flag comes at a risk for existing Redshift columns, as the `name` attribute of a redshift column was currently being used. Therefore, to change a Redshift columns' `name` will essentially create a new column and delete the old one. This will cause data loss. If you choose to enable this flag, ensure that upon intial deployment (the first deployment after setting this feature flag), the `name` attribute of every column is not changed. After the intial deployment, you can freely change the `name` attribute of a column.

  *cdk.json*

  ```json
  {
    "context": {
      "@aws-cdk/aws-redshift:columnId": true
    }
  }
  ```

  * `@aws-cdk/aws-stepfunctions-tasks:enableEmrServicePolicyV2`

  Enable this feature flag to use the `AmazonEMRServicePolicy_v2` managed policies for the EMR service role.

  This is a feature flag as the old behavior will be deprecated, but some resources may require manual
  intervention since they might not have the appropriate tags propagated automatically.

  https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-managed-iam-policies.html

  *cdk.json*

  ```json
  {
    "context": {
      "@aws-cdk/aws-stepfunctions-tasks:enableEmrServicePolicyV2": true
    }
  }
  ```

  * `@aws-cdk/core:includePrefixInUniqueNameGeneration`

  Enable this feature flag to include the stack's prefixes to the name generation process.

  Not doing so can cause the name of stack to exceed 128 characters:

  * The name generation ensures it doesn't exceed 128 characters
  * Without this feature flag, the prefix is prepended to the generated name, which result can exceed 128 characters

  This is a feature flag as it changes the name generated for stacks. Any CDK application deployed prior this fix will
  most likely be generated with a new name, causing the stack to be recreated with the new name, and then deleting the old one.
  For applications running on production environments this can be unmanageable.

  *cdk.json*

  ```json
  {
    "context": {
      "@aws-cdk/core:includePrefixInUniqueNameGeneration": true
    }
  }
  ```

  * `@aws-cdk/aws-lambda-nodejs:useLatestRuntimeVersion`

  Enable this feature flag to automatically use the latest available NodeJS version in the aws-lambda-nodejse.Function construct.

  This allows creation of new functions using a version that will automatically stay up to date without breaking bundling of existing functions that externalize packages included in their environemnt such as `aws-sdk`.

  Functions defined previously will continue to function correctly as long as they pass an explicit runtime version, or do not exclude packages during bundling.

  *cdk.json*

  ```json
  {
    "context": {
      "@aws-cdk/aws-lambda-nodejs:useLatestRuntimeVersion": true
    }
  }
  ```

  * `@aws-cdk/aws-codepipeline-actions:useNewDefaultBranchForCodeCommitSource`

  Enable this feature flag to update the default branch for CodeCommit source actions to `main`.

  Previously, the default branch for CodeCommit source actions was set to `master`.
  However, this convention is no longer supported, and repositories created after March 2021 now have `main` as
  their default branch.

  *cdk.json*

  ```json
  {
    "context": {
      "@aws-cdk/aws-codepipeline-actions:useNewDefaultBranchForCodeCommitSource": true
    }
  }
  ```

  * `@aws-cdk/aws-cloudwatch-actions:changeLambdaPermissionLogicalIdForLambdaAction`

  Enable this feature flag to change the logical ID of the `LambdaPermission` for the `LambdaAction` to include an alarm ID.

  Previously, only one alarm with the `LambdaAction` could be created per Lambda.
  This flag allows multiple alarms with the `LambdaAction` for the same Lambda to be created.

  *cdk.json*

  ```json
  {
    "context": {
      "@aws-cdk/aws-cloudwatch-actions:changeLambdaPermissionLogicalIdForLambdaAction": true
    }
  }
  ```

  * `@aws-cdk/aws-codepipeline:crossAccountKeysDefaultValueToFalse`

  Enables Pipeline to set the default value for `crossAccountKeys` to false.

  When this feature flag is enabled, and the `crossAccountKeys` property is not provided in a `Pipeline`
  construct, the construct automatically defaults the value of this property to false.

  *cdk.json*

  ```json
  {
    "context": {
      "@aws-cdk/aws-codepipeline:crossAccountKeysDefaultValueToFalse": true
    }
  }
  ```

  * `@aws-cdk/aws-codepipeline:defaultPipelineTypeToV2`

  Enables Pipeline to set the default pipeline type to V2.

  When this feature flag is enabled, and the `pipelineType` property is not provided in a `Pipeline`
  construct, the construct automatically defaults the value of this property to `PipelineType.V2`.

  *cdk.json*

  ```json
  {
    "context": {
      "@aws-cdk/aws-codepipeline:defaultPipelineTypeToV2": true
    }
  }
  ```

  * `@aws-cdk/aws-kms:reduceCrossAccountRegionPolicyScope`

  Reduce resource scope of the IAM Policy created from KMS key grant to granting key only.

  When this feature flag is enabled and calling KMS key grant method, the created IAM policy will reduce the resource scope from
  '*' to this specific granting KMS key.

  *cdk.json*

  ```json
  {
    "context": {
      "@aws-cdk/aws-kms:reduceCrossAccountRegionPolicyScope": true
    }
  }
  ```

  * `@aws-cdk/aws-eks:nodegroupNameAttribute`

  When enabled, nodegroupName attribute of the provisioned EKS NodeGroup will not have the cluster name prefix.

  When this feature flag is enabled, the nodegroupName attribute will be exactly the name of the nodegroup
  without any prefix.

  *cdk.json*

  ```json
  {
    "context": {
      "@aws-cdk/aws-eks:nodegroupNameAttribute": true
    }
  }
  ```

  * `@aws-cdk/aws-ec2:ebsDefaultGp3Volume`

  When enabled, the default volume type of the EBS volume will be GP3.

  When this featuer flag is enabled, the default volume type of the EBS volume will be `EbsDeviceVolumeType.GENERAL_PURPOSE_SSD_GP3`

  *cdk.json*

  ```json
  {
    "context": {
      "@aws-cdk/aws-ec2:ebsDefaultGp3Volume": true
    }
  }
  ```

  * `@aws-cdk/aws-ecs:removeDefaultDeploymentAlarm`

  When enabled, remove default deployment alarm settings.

  When this featuer flag is enabled, remove the default deployment alarm settings when creating a AWS ECS service.

  *cdk.json*

  ```json
  {
    "context": {
      "@aws-cdk/aws-ec2:ebsDefaultGp3Volume": true
    }
  }
  ```

  * `@aws-cdk/aws-stepfunctions-tasks:ecsReduceRunTaskPermissions`

  When enabled, IAM Policy created to run tasks won't include the task definition ARN, only the revision ARN.

  When this feature flag is enabled, the IAM Policy created to run tasks won't include the task definition ARN, only the revision ARN.
  The revision ARN is more specific than the task definition ARN. See https://docs.aws.amazon.com/step-functions/latest/dg/ecs-iam.html
  for more details.

  *cdk.json*

  ```json
  {
    "context": {
      "@aws-cdk/aws-stepfunctions-tasks:ecsReduceRunTaskPermissions": true
    }
  }
  ```

  * `@aws-cdk/aws-stepfunctions-taks:useNewS3UriParametersForBedrockInvokeModelTask`

  When enabled, use new props for S3 URI under `input` and `output` fields in task definition of state machine for bedrock invoke model.

  When this feature flag is enabled, use newly introduced props `s3InputUri` and `s3OutputUri` to populate S3 uri under input and output fields in state machine task definition for Bedrock invoke model.

  *cdk.json*

  ```json
  {
    "context": {
      "@aws-cdk/aws-stepfunctions-tasks:useNewS3UriParametersForBedrockInvokeModelTask": true
    }
  }
  ```

  * `@aws-cdk/aws-ecs:reduceEc2FargateCloudWatchPermissions`

  Currently, we will automatically add a number of cloudwatch permissions to the task role when no cloudwatch log group is
  specified as logConfiguration and it will grant 'Resources': ['*'] to the task role.

  When this feature flag is enabled, we will only grant the necessary permissions when users specify cloudwatch log group.

  *cdk.json*

  ```json
  {
    "context": {
      "@aws-cdk/aws-ecs:reduceEc2FargateCloudWatchPermissions": true
    }
  }
  ```

  * `@aws-cdk/aws-ec2:ec2SumTImeoutEnabled`

  Currently is both initOptions.timeout and resourceSignalTimeout are both specified in the options for creating an EC2 Instance, only the value from 'resourceSignalTimeout' will be used.

  When this feature flag is enabled, if both initOptions.timeout and resourceSignalTimeout are specified, the values will to be summed together.

  *cdk.json*

  ```json
  {
    "context": {
      "@aws-cdk/aws-ec2:ec2SumTImeoutEnabled": true
    }
  }
  ```

  * `@aws-cdk/aws-appsync:appSyncGraphQLAPIScopeLambdaPermission`

  Currently, when using a Lambda authorizer with an AppSync GraphQL API, the AWS CDK automatically generates the necessary AWS::Lambda::Permission to allow the AppSync API to invoke the Lambda authorizer. This permission is overly permissive because it lacks a SourceArn, meaning it allows invocations from any source.

  When this feature flag is enabled, the AWS::Lambda::Permission will be properly scoped with the SourceArn corresponding to the specific AppSync GraphQL API.

  *cdk.json*

  ```json
  {
    "context": {
      "@aws-cdk/aws-ec2:appSyncGraphQLAPIScopeLambdaPermission": true
    }
  }
  ```

  * `@aws-cdk/aws-rds:setCorrectValueForDatabaseInstanceReadReplicaInstanceResourceId`

  When enabled, the value of property `instanceResourceId` in construct `DatabaseInstanceReadReplica` will be set to the correct value which is `DbiResourceId` instead of currently `DbInstanceArn`* (fix)

  When this feature flag is enabled, the value of that property will be as expected set to `DbiResourceId` attribute, and that will fix the grantConnect method.

  *cdk.json*

  ```json
  {
    "context": {
      "@aws-cdk/aws-rds:setCorrectValueForDatabaseInstanceReadReplicaInstanceResourceId": true
    }
  }
  ```

  * `@aws-cdk/aws-lambda-nodejs:sdkV3ExcludeSmithyPackages`

  Currently, when bundling Lambda functions with the non-latest runtime that supports AWS SDK JavaScript (v3), only the `@aws-sdk/*` packages are excluded by default.
  However, this can cause version mismatches between the `@aws-sdk/*` and `@smithy/*` packages, as they are tightly coupled dependencies in AWS SDK v3.

  When this feature flag is enabled, both `@aws-sdk/*` and `@smithy/*` packages will be excluded during the bundling process. This ensures that no mismatches
  occur between these tightly coupled dependencies when using the AWS SDK v3 in Lambda functions.

  *cdk.json*

  ```json
  {
    "context": {
      "@aws-cdk/aws-lambda-nodejs:sdkV3ExcludeSmithyPackages": true
    }
  }
  ```


pkgId: e482d9839efa303ebf08f5829c4380b4353ba8f6a830177dbf589949a41d8f74
name: python-aws-cdk.cx-api
arch: src
version: 2.167.0
epoch: 0
release: 1
summary: Cloud executable protocol
url: https://github.com/aws/aws-cdk
rpm_license: Apache-2.0
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-cdk.cx-api-2.167.0-1.src.rpm
checksum_type: sha256
description:
  This module is part of the [AWS Cloud Development Kit](https://github.com/aws/aws-cdk) project.



  * `@aws-cdk/aws-s3:createDefaultLoggingPolicy`

  Enable this feature flag to create an S3 bucket policy by default in cases where
  an AWS service would automatically create the Policy if one does not exist.

  For example, in order to send VPC flow logs to an S3 bucket, there is a specific Bucket Policy
  that needs to be attached to the bucket. If you create the bucket without a policy and then add the
  bucket as the flow log destination, the service will automatically create the bucket policy with the
  necessary permissions. If you were to then try and add your own bucket policy CloudFormation will throw
  and error indicating that a bucket policy already exists.

  In cases where we know what the required policy is we can go ahead and create the policy so we can
  remain in control of it.

  https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-and-resource-policy.html#AWS-logs-infrastructure-S3

  *cdk.json*

  ```json
  {
    "context": {
      "@aws-cdk/aws-s3:createDefaultLoggingPolicy": true
    }
  }
  ```

  * `@aws-cdk/aws-sns-subscriptions:restrictSqsDescryption`

  Enable this feature flag to restrict the decryption of a SQS queue, which is subscribed to a SNS topic, to
  only the topic which it is subscribed to and not the whole SNS service of an account.

  Previously the decryption was only restricted to the SNS service principal. To make the SQS subscription more
  secure, it is a good practice to restrict the decryption further and only allow the connected SNS topic to decryption
  the subscribed queue.

  *cdk.json*

  ```json
  {
    "context": {
      "@aws-cdk/aws-sns-subscriptions:restrictSqsDescryption": true
    }
  }
  ```

  * @aws-cdk/aws-apigateway:disableCloudWatchRole

  Enable this feature flag to change the default behavior for aws-apigateway.RestApi and aws-apigateway.SpecRestApi
  to *not* create a CloudWatch role and Account. There is only a single ApiGateway account per AWS
  environment which means that each time you create a RestApi in your account the ApiGateway account
  is overwritten. If at some point the newest RestApi is deleted, the ApiGateway Account and CloudWatch
  role will also be deleted, breaking any existing ApiGateways that were depending on them.

  When this flag is enabled you should either create the ApiGateway account and CloudWatch role
  separately *or* only enable the cloudWatchRole on a single RestApi.

  *cdk.json*

  ```json
  {
    "context": {
      "@aws-cdk/aws-apigateway:disableCloudWatchRole": true
    }
  }
  ```

  * `@aws-cdk/core:enablePartitionLiterals`

  Enable this feature flag to have `Stack.partition` return a literal string for a stack's partition
  when the stack has a known region configured.  If the region is undefined, or set to an unknown value, the
  `Stack.partition` will be the CloudFormation intrinsic value `AWS::Partition`.  Without this feature flag,
  `Stack.partition` always returns the CloudFormation intrinsic value `AWS::Partition`.

  This feature will often simplify ARN strings in CDK generated templates, for example:

  ```yaml
   Principal:
     AWS:
       Fn::Join:
         - ""
         - - "arn:"
           - Ref: AWS::Partition
           - :iam::123456789876:root
  ```

  becomes:

  ```yaml
   Principal:
     AWS: "arn:aws:iam::123456789876:root"
  ```

  * `@aws-cdk/aws-ecs:disableExplicitDeploymentControllerForCircuitBreaker`

  Enable this feature flag to avoid setting the "ECS" deployment controller when adding a circuit breaker to an
  ECS Service, as this will trigger a full replacement which fails to deploy when using set service names.
  This does not change any behaviour as the default deployment controller when it is not defined is ECS.

  *cdk.json*

  ```json
  {
    "context": {
      "@aws-cdk/aws-ecs:disableExplicitDeploymentControllerForCircuitBreaker": true
    }
  }
  ```

  * `@aws-cdk/aws-s3:serverAccessLogsUseBucketPolicy`

  Enable this feature flag to use S3 Bucket Policy for granting permission fo Server Access Logging
  rather than using the canned `LogDeliveryWrite` ACL. ACLs do not work when Object Ownership is
  enabled on the bucket.

  This flag uses a Bucket Policy statement to allow Server Access Log delivery, following best
  practices for S3.

  https://docs.aws.amazon.com/AmazonS3/latest/userguide/enable-server-access-logging.html

  ```json
  {
    "context": {
      "@aws-cdk/aws-s3:serverAccessLogsUseBucketPolicy": true
    }
  }
  ```

  * `@aws-cdk/aws-rds:databaseProxyUniqueResourceName`

  Enable this feature flag to use unique resource names for each `DatabaseProxy`.

  Previously, the default behavior for `DatabaseProxy` was to use `id` of the constructor for `dbProxyName`.
  In this case, users couldn't deploy `DatabaseProxy`s that have the same `id` in the same region.

  This is a feature flag as the old behavior was technically incorrect, but users may have come to depend on it.

  ```json
  {
    "context": {
      "@aws-cdk/aws-rds:databaseProxyUniqueResourceName": true
    }
  }
  ```

  * `@aws-cdk/aws-redshift:columnId`

  Enable this feature flag to allow the CDK to track changes in Redshift columns through their `id` attribute. This is a breaking change, as the `name` attribute was currently being used to track changes to Redshift columns.

  Enabling this feature flag comes at a risk for existing Redshift columns, as the `name` attribute of a redshift column was currently being used. Therefore, to change a Redshift columns' `name` will essentially create a new column and delete the old one. This will cause data loss. If you choose to enable this flag, ensure that upon intial deployment (the first deployment after setting this feature flag), the `name` attribute of every column is not changed. After the intial deployment, you can freely change the `name` attribute of a column.

  *cdk.json*

  ```json
  {
    "context": {
      "@aws-cdk/aws-redshift:columnId": true
    }
  }
  ```

  * `@aws-cdk/aws-stepfunctions-tasks:enableEmrServicePolicyV2`

  Enable this feature flag to use the `AmazonEMRServicePolicy_v2` managed policies for the EMR service role.

  This is a feature flag as the old behavior will be deprecated, but some resources may require manual
  intervention since they might not have the appropriate tags propagated automatically.

  https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-managed-iam-policies.html

  *cdk.json*

  ```json
  {
    "context": {
      "@aws-cdk/aws-stepfunctions-tasks:enableEmrServicePolicyV2": true
    }
  }
  ```

  * `@aws-cdk/core:includePrefixInUniqueNameGeneration`

  Enable this feature flag to include the stack's prefixes to the name generation process.

  Not doing so can cause the name of stack to exceed 128 characters:

  * The name generation ensures it doesn't exceed 128 characters
  * Without this feature flag, the prefix is prepended to the generated name, which result can exceed 128 characters

  This is a feature flag as it changes the name generated for stacks. Any CDK application deployed prior this fix will
  most likely be generated with a new name, causing the stack to be recreated with the new name, and then deleting the old one.
  For applications running on production environments this can be unmanageable.

  *cdk.json*

  ```json
  {
    "context": {
      "@aws-cdk/core:includePrefixInUniqueNameGeneration": true
    }
  }
  ```

  * `@aws-cdk/aws-lambda-nodejs:useLatestRuntimeVersion`

  Enable this feature flag to automatically use the latest available NodeJS version in the aws-lambda-nodejse.Function construct.

  This allows creation of new functions using a version that will automatically stay up to date without breaking bundling of existing functions that externalize packages included in their environemnt such as `aws-sdk`.

  Functions defined previously will continue to function correctly as long as they pass an explicit runtime version, or do not exclude packages during bundling.

  *cdk.json*

  ```json
  {
    "context": {
      "@aws-cdk/aws-lambda-nodejs:useLatestRuntimeVersion": true
    }
  }
  ```

  * `@aws-cdk/aws-codepipeline-actions:useNewDefaultBranchForCodeCommitSource`

  Enable this feature flag to update the default branch for CodeCommit source actions to `main`.

  Previously, the default branch for CodeCommit source actions was set to `master`.
  However, this convention is no longer supported, and repositories created after March 2021 now have `main` as
  their default branch.

  *cdk.json*

  ```json
  {
    "context": {
      "@aws-cdk/aws-codepipeline-actions:useNewDefaultBranchForCodeCommitSource": true
    }
  }
  ```

  * `@aws-cdk/aws-cloudwatch-actions:changeLambdaPermissionLogicalIdForLambdaAction`

  Enable this feature flag to change the logical ID of the `LambdaPermission` for the `LambdaAction` to include an alarm ID.

  Previously, only one alarm with the `LambdaAction` could be created per Lambda.
  This flag allows multiple alarms with the `LambdaAction` for the same Lambda to be created.

  *cdk.json*

  ```json
  {
    "context": {
      "@aws-cdk/aws-cloudwatch-actions:changeLambdaPermissionLogicalIdForLambdaAction": true
    }
  }
  ```

  * `@aws-cdk/aws-codepipeline:crossAccountKeysDefaultValueToFalse`

  Enables Pipeline to set the default value for `crossAccountKeys` to false.

  When this feature flag is enabled, and the `crossAccountKeys` property is not provided in a `Pipeline`
  construct, the construct automatically defaults the value of this property to false.

  *cdk.json*

  ```json
  {
    "context": {
      "@aws-cdk/aws-codepipeline:crossAccountKeysDefaultValueToFalse": true
    }
  }
  ```

  * `@aws-cdk/aws-codepipeline:defaultPipelineTypeToV2`

  Enables Pipeline to set the default pipeline type to V2.

  When this feature flag is enabled, and the `pipelineType` property is not provided in a `Pipeline`
  construct, the construct automatically defaults the value of this property to `PipelineType.V2`.

  *cdk.json*

  ```json
  {
    "context": {
      "@aws-cdk/aws-codepipeline:defaultPipelineTypeToV2": true
    }
  }
  ```

  * `@aws-cdk/aws-kms:reduceCrossAccountRegionPolicyScope`

  Reduce resource scope of the IAM Policy created from KMS key grant to granting key only.

  When this feature flag is enabled and calling KMS key grant method, the created IAM policy will reduce the resource scope from
  '*' to this specific granting KMS key.

  *cdk.json*

  ```json
  {
    "context": {
      "@aws-cdk/aws-kms:reduceCrossAccountRegionPolicyScope": true
    }
  }
  ```

  * `@aws-cdk/aws-eks:nodegroupNameAttribute`

  When enabled, nodegroupName attribute of the provisioned EKS NodeGroup will not have the cluster name prefix.

  When this feature flag is enabled, the nodegroupName attribute will be exactly the name of the nodegroup
  without any prefix.

  *cdk.json*

  ```json
  {
    "context": {
      "@aws-cdk/aws-eks:nodegroupNameAttribute": true
    }
  }
  ```

  * `@aws-cdk/aws-ec2:ebsDefaultGp3Volume`

  When enabled, the default volume type of the EBS volume will be GP3.

  When this featuer flag is enabled, the default volume type of the EBS volume will be `EbsDeviceVolumeType.GENERAL_PURPOSE_SSD_GP3`

  *cdk.json*

  ```json
  {
    "context": {
      "@aws-cdk/aws-ec2:ebsDefaultGp3Volume": true
    }
  }
  ```

  * `@aws-cdk/aws-ecs:removeDefaultDeploymentAlarm`

  When enabled, remove default deployment alarm settings.

  When this featuer flag is enabled, remove the default deployment alarm settings when creating a AWS ECS service.

  *cdk.json*

  ```json
  {
    "context": {
      "@aws-cdk/aws-ec2:ebsDefaultGp3Volume": true
    }
  }
  ```

  * `@aws-cdk/aws-stepfunctions-tasks:ecsReduceRunTaskPermissions`

  When enabled, IAM Policy created to run tasks won't include the task definition ARN, only the revision ARN.

  When this feature flag is enabled, the IAM Policy created to run tasks won't include the task definition ARN, only the revision ARN.
  The revision ARN is more specific than the task definition ARN. See https://docs.aws.amazon.com/step-functions/latest/dg/ecs-iam.html
  for more details.

  *cdk.json*

  ```json
  {
    "context": {
      "@aws-cdk/aws-stepfunctions-tasks:ecsReduceRunTaskPermissions": true
    }
  }
  ```

  * `@aws-cdk/aws-stepfunctions-taks:useNewS3UriParametersForBedrockInvokeModelTask`

  When enabled, use new props for S3 URI under `input` and `output` fields in task definition of state machine for bedrock invoke model.

  When this feature flag is enabled, use newly introduced props `s3InputUri` and `s3OutputUri` to populate S3 uri under input and output fields in state machine task definition for Bedrock invoke model.

  *cdk.json*

  ```json
  {
    "context": {
      "@aws-cdk/aws-stepfunctions-tasks:useNewS3UriParametersForBedrockInvokeModelTask": true
    }
  }
  ```

  * `@aws-cdk/aws-ecs:reduceEc2FargateCloudWatchPermissions`

  Currently, we will automatically add a number of cloudwatch permissions to the task role when no cloudwatch log group is
  specified as logConfiguration and it will grant 'Resources': ['*'] to the task role.

  When this feature flag is enabled, we will only grant the necessary permissions when users specify cloudwatch log group.

  *cdk.json*

  ```json
  {
    "context": {
      "@aws-cdk/aws-ecs:reduceEc2FargateCloudWatchPermissions": true
    }
  }
  ```

  * `@aws-cdk/aws-ec2:ec2SumTImeoutEnabled`

  Currently is both initOptions.timeout and resourceSignalTimeout are both specified in the options for creating an EC2 Instance, only the value from 'resourceSignalTimeout' will be used.

  When this feature flag is enabled, if both initOptions.timeout and resourceSignalTimeout are specified, the values will to be summed together.

  *cdk.json*

  ```json
  {
    "context": {
      "@aws-cdk/aws-ec2:ec2SumTImeoutEnabled": true
    }
  }
  ```

  * `@aws-cdk/aws-appsync:appSyncGraphQLAPIScopeLambdaPermission`

  Currently, when using a Lambda authorizer with an AppSync GraphQL API, the AWS CDK automatically generates the necessary AWS::Lambda::Permission to allow the AppSync API to invoke the Lambda authorizer. This permission is overly permissive because it lacks a SourceArn, meaning it allows invocations from any source.

  When this feature flag is enabled, the AWS::Lambda::Permission will be properly scoped with the SourceArn corresponding to the specific AppSync GraphQL API.

  *cdk.json*

  ```json
  {
    "context": {
      "@aws-cdk/aws-ec2:appSyncGraphQLAPIScopeLambdaPermission": true
    }
  }
  ```

  * `@aws-cdk/aws-rds:setCorrectValueForDatabaseInstanceReadReplicaInstanceResourceId`

  When enabled, the value of property `instanceResourceId` in construct `DatabaseInstanceReadReplica` will be set to the correct value which is `DbiResourceId` instead of currently `DbInstanceArn`* (fix)

  When this feature flag is enabled, the value of that property will be as expected set to `DbiResourceId` attribute, and that will fix the grantConnect method.

  *cdk.json*

  ```json
  {
    "context": {
      "@aws-cdk/aws-rds:setCorrectValueForDatabaseInstanceReadReplicaInstanceResourceId": true
    }
  }
  ```

  * `@aws-cdk/aws-lambda-nodejs:sdkV3ExcludeSmithyPackages`

  Currently, when bundling Lambda functions with the non-latest runtime that supports AWS SDK JavaScript (v3), only the `@aws-sdk/*` packages are excluded by default.
  However, this can cause version mismatches between the `@aws-sdk/*` and `@smithy/*` packages, as they are tightly coupled dependencies in AWS SDK v3.

  When this feature flag is enabled, both `@aws-sdk/*` and `@smithy/*` packages will be excluded during the bundling process. This ensures that no mismatches
  occur between these tightly coupled dependencies when using the AWS SDK v3 in Lambda functions.

  *cdk.json*

  ```json
  {
    "context": {
      "@aws-cdk/aws-lambda-nodejs:sdkV3ExcludeSmithyPackages": true
    }
  }
  ```

  * `@aws-cdk/aws-dynamodb:resourcePolicyPerReplica`

  If this flag is not set, the default behavior for `TableV2` is to use a different `resourcePolicy` for each replica.

  If this flag is set to false, the behavior is that each replica shares the same `resourcePolicy` as the source table.
  This will prevent you from creating a new table which has an additional replica and a resource policy.

  This is a feature flag as the old behavior was technically incorrect but users may have come to depend on it.

  *cdk.json*

  ```json
  {
    "context": {
      "@aws-cdk/aws-dynamodb:resourcePolicyPerReplica": false,
    },
  }
  ```


pkgId: 02ef012b0dca51d31252dc5de03d71071acb3b29ff59908cf3b4c05f69e5fbd2
name: python-aws-cdk.integ-tests-alpha
arch: src
version: 2.159.0a0
epoch: 0
release: 1
summary: CDK Integration Testing Constructs
url: https://github.com/aws/aws-cdk
rpm_license: Apache-2.0
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-cdk.integ-tests-alpha-2.159.0a0-1.src.rpm
checksum_type: sha256
description:
  <!--END STABILITY BANNER-->

  This library is meant to be used in combination with the [integ-runner](https://github.com/aws/aws-cdk/tree/main/packages/%40aws-cdk/integ-runner) CLI
  to enable users to write and execute integration tests for AWS CDK Constructs.
  An integration test should be defined as a CDK application, and
  there should be a 1:1 relationship between an integration test and a CDK application.
  So for example, in order to create an integration test called `my-function`
  we would need to create a file to contain our integration test application.
  *test/integ.my-function.ts*
  ```python
  app = App()
  stack = Stack()
  lambda_.Function(stack, "MyFunction",
      runtime=lambda_.Runtime.NODEJS_LATEST,
      handler="index.handler",
      code=lambda_.Code.from_asset(path.join(__dirname, "lambda-handler"))
  )
  ```
  This is a self contained CDK application which we could deploy by running
  ```bash
  cdk deploy --app 'node test/integ.my-function.js'
  ```
  In order to turn this into an integration test, all that is needed is to
  use the `IntegTest` construct.
  ```python


  IntegTest(app, "Integ", test_cases=[stack])
  ```
  You will notice that the `stack` is registered to the `IntegTest` as a test case.
  Each integration test can contain multiple test cases, which are just instances
  of a stack. See the [Usage](#usage) section for more details.


  Suppose you have a simple stack, that only encapsulates a Lambda function with a
  certain handler:
  ```python
  class StackUnderTest(Stack):
      def __init__(self, scope, id, *, architecture=None, description=None, env=None, stackName=None, tags=None, synthesizer=None, terminationProtection=None, analyticsReporting=None, crossRegionReferences=None, permissionsBoundary=None, suppressTemplateIndentation=None):
          super().__init__(scope, id, architecture=architecture, description=description, env=env, stackName=stackName, tags=tags, synthesizer=synthesizer, terminationProtection=terminationProtection, analyticsReporting=analyticsReporting, crossRegionReferences=crossRegionReferences, permissionsBoundary=permissionsBoundary, suppressTemplateIndentation=suppressTemplateIndentation)
          lambda_.Function(self, "Handler",
              runtime=lambda_.Runtime.NODEJS_LATEST,
              handler="index.handler",
              code=lambda_.Code.from_asset(path.join(__dirname, "lambda-handler")),
              architecture=architecture
          )
  ```
  You may want to test this stack under different conditions. For example, we want
  this stack to be deployed correctly, regardless of the architecture we choose
  for the Lambda function. In particular, it should work for both `ARM_64` and
  `X86_64`. So you can create an `IntegTestCase` that exercises both scenarios:
  ```python
  class StackUnderTest(Stack):
      def __init__(self, scope, id, *, architecture=None, description=None, env=None, stackName=None, tags=None, synthesizer=None, terminationProtection=None, analyticsReporting=None, crossRegionReferences=None, permissionsBoundary=None, suppressTemplateIndentation=None):
          super().__init__(scope, id, architecture=architecture, description=description, env=env, stackName=stackName, tags=tags, synthesizer=synthesizer, terminationProtection=terminationProtection, analyticsReporting=analyticsReporting, crossRegionReferences=crossRegionReferences, permissionsBoundary=permissionsBoundary, suppressTemplateIndentation=suppressTemplateIndentation)
          lambda_.Function(self, "Handler",
              runtime=lambda_.Runtime.NODEJS_LATEST,
              handler="index.handler",
              code=lambda_.Code.from_asset(path.join(__dirname, "lambda-handler")),
              architecture=architecture
          )

  app = App()
  IntegTest(app, "DifferentArchitectures",
      test_cases=[
          StackUnderTest(app, "Stack1",
              architecture=lambda_.Architecture.ARM_64
          ),
          StackUnderTest(app, "Stack2",
              architecture=lambda_.Architecture.X86_64
          )
      ]
  )
  ```
  This is all the instruction you need for the integration test runner to know
  which stacks to synthesize, deploy and destroy. But you may also need to
  customize the behavior of the runner by changing its parameters. For example:
  ```python
  app = App()
  stack_under_test = Stack(app, "StackUnderTest")
  stack = Stack(app, "stack")
  test_case = IntegTest(app, "CustomizedDeploymentWorkflow",
      test_cases=[stack_under_test],
      diff_assets=True,
      stack_update_workflow=True,
      cdk_command_options=CdkCommands(
          deploy=DeployCommand(
              args=DeployOptions(
                  require_approval=RequireApproval.NEVER,
                  json=True
              )
          ),
          destroy=DestroyCommand(
              args=DestroyOptions(
                  force=True
              )
          )
      )
  )
  ```

  In the majority of cases an integration test will contain a single `IntegTestCase`.
  By default when you create an `IntegTest` an `IntegTestCase` is created for you
  and all of your test cases are registered to this `IntegTestCase`. The `IntegTestCase`
  and `IntegTestCaseStack` constructs are only needed when it is necessary to
  defined different options for individual test cases.
  For example, you might want to have one test case where `diffAssets` is enabled.
  ```python


  test_case_with_assets = IntegTestCaseStack(app, "TestCaseAssets",
      diff_assets=True
  )
  IntegTest(app, "Integ", test_cases=[stack_under_test, test_case_with_assets])
  ```

  This library also provides a utility to make assertions against the infrastructure that the integration test deploys.
  There are two main scenarios in which assertions are created.
  * Part of an integration test using `integ-runner`
  In this case you would create an integration test using the `IntegTest` construct and then make assertions using the `assert` property.
  You should **not** utilize the assertion constructs directly, but should instead use the `methods` on `IntegTest.assertions`.
  ```python


  integ = IntegTest(app, "Integ", test_cases=[stack])
  integ.assertions.aws_api_call("S3", "getObject")
  ```
  By default an assertions stack is automatically generated for you. You may however provide your own stack to use.
  ```python



  integ = IntegTest(app, "Integ", test_cases=[stack], assertion_stack=assertion_stack)
  integ.assertions.aws_api_call("S3", "getObject")
  ```
  * Part of a  normal CDK deployment
  In this case you may be using assertions as part of a normal CDK deployment in order to make an assertion on the infrastructure
  before the deployment is considered successful. In this case you can utilize the assertions constructs directly.
  ```python

  AwsApiCall(my_app_stack, "GetObject",
      service="S3",
      api="getObject"
  )
  ```

  Assertions are created by using the `DeployAssert` construct. This construct creates it's own `Stack` separate from
  any stacks that you create as part of your integration tests. This `Stack` is treated differently from other stacks
  by the `integ-runner` tool. For example, this stack will not be diffed by the `integ-runner`.
  `DeployAssert` also provides utilities to register your own assertions.
  ```python



  integ = IntegTest(app, "Integ", test_cases=[stack])
  integ.assertions.expect("CustomAssertion",
      ExpectedResult.object_like({"foo": "bar"}),
      ActualResult.from_custom_resource(my_custom_resource, "data"))
  ```
  In the above example an assertion is created that will trigger a user defined `CustomResource`
  and assert that the `data` attribute is equal to `{ foo: 'bar' }`.

  A common method to retrieve the "actual" results to compare with what is expected is to make an
  API call to receive some data. This library does this by utilizing CloudFormation custom resources
  which means that CloudFormation will call out to a Lambda Function which will
  make the API call.

  Using the `HttpApiCall` will use the
  [node-fetch](https://github.com/node-fetch/node-fetch) JavaScript library to
  make the HTTP call.
  This can be done by using the class directory (in the case of a normal deployment):
  ```python

  HttpApiCall(stack, "MyAsssertion",
      url="https://example-api.com/abc"
  )
  ```
  Or by using the `httpApiCall` method on `DeployAssert` (when writing integration tests):
  ```python


  integ = IntegTest(app, "Integ",
      test_cases=[stack]
  )
  integ.assertions.http_api_call("https://example-api.com/abc")
  ```

  Using the `AwsApiCall` construct will use the AWS JavaScript SDK to make the API call.
  This can be done by using the class directory (in the case of a normal deployment):
  ```python

  AwsApiCall(stack, "MyAssertion",
      service="SQS",
      api="receiveMessage",
      parameters={
          "QueueUrl": "url"
      }
  )
  ```
  Or by using the `awsApiCall` method on `DeployAssert` (when writing integration tests):
  ```python


  integ = IntegTest(app, "Integ",
      test_cases=[stack]
  )
  integ.assertions.aws_api_call("SQS", "receiveMessage", {
      "QueueUrl": "url"
  })
  ```
  You must specify the `service` and the `api` when using The `AwsApiCall` construct.
  The `service` is the name of an AWS service, in one of the following forms:
  * An AWS SDK for JavaScript v3 package name (`@aws-sdk/client-api-gateway`)
  * An AWS SDK for JavaScript v3 client name (`api-gateway`)
  * An AWS SDK for JavaScript v2 constructor name (`APIGateway`)
  * A lowercase AWS SDK for JavaScript v2 constructor name (`apigateway`)
  The `api` is the name of an AWS API call, in one of the following forms:
  * An API call name as found in the API Reference documentation (`GetObject`)
  * The API call name starting with a lowercase letter (`getObject`)
  * The AWS SDK for JavaScript v3 command class name (`GetObjectCommand`)
  By default, the `AwsApiCall` construct will automatically add the correct IAM policies
  to allow the Lambda function to make the API call. It does this based on the `service`
  and `api` that is provided. In the above example the service is `SQS` and the api is
  `receiveMessage` so it will create a policy with `Action: 'sqs:ReceiveMessage`.
  There are some cases where the permissions do not exactly match the service/api call, for
  example the S3 `listObjectsV2` api. In these cases it is possible to add the correct policy
  by accessing the `provider` object.
  ```python



  api_call = integ.assertions.aws_api_call("S3", "listObjectsV2", {
      "Bucket": "mybucket"
  })
  api_call.provider.add_to_role_policy({
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:ListBucket"],
      "Resource": ["*"]
  })
  ```
  Note that addToRolePolicy() uses direct IAM JSON policy blobs, not a iam.PolicyStatement
  object like you will see in the rest of the CDK.

  This library currently provides the ability to assert that two values are equal
  to one another by utilizing the `EqualsAssertion` class. This utilizes a Lambda
  backed `CustomResource` which in tern uses the [Match](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.assertions.Match.html) utility from the
  [@aws-cdk/assertions](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.assertions-readme.html) library.
  ```python




  integ = IntegTest(app, "Integ",
      test_cases=[stack]
  )
  integ.assertions.invoke_function(
      function_name=fn.function_name,
      invocation_type=InvocationType.EVENT,
      payload=JSON.stringify({"status": "OK"})
  )
  message = integ.assertions.aws_api_call("SQS", "receiveMessage", {
      "QueueUrl": queue.queue_url,
      "WaitTimeSeconds": 20
  })
  message.assert_at_path("Messages.0.Body", ExpectedResult.object_like({
      "request_context": {
          "condition": "Success"
      },
      "request_payload": {
          "status": "OK"
      },
      "response_context": {
          "status_code": 200
      },
      "response_payload": "success"
  }))
  ```

  `integ-tests` also provides a `Match` utility similar to the `@aws-cdk/assertions` module. `Match`
  can be used to construct the `ExpectedResult`. While the utility is similar, only a subset of methods are currently available on the `Match` utility of this module: `arrayWith`, `objectLike`, `stringLikeRegexp` and `serializedJson`.
  ```python

  message.expect(ExpectedResult.object_like({
      "Messages": Match.array_with([{
          "Payload": Match.serialized_json({"key": "value"})
      }, {
          "Body": {
              "Values": Match.array_with([{"Asdf": 3}]),
              "Message": Match.string_like_regexp("message")
          }
      }
      ])
  }))
  ```


  In this example there is a Lambda Function that is invoked and
  we assert that the payload that is returned is equal to '200'.
  ```python


  stack = Stack(app, "cdk-integ-lambda-bundling")
  integ = IntegTest(app, "IntegTest",
      test_cases=[stack]
  )
  invoke = integ.assertions.invoke_function(
      function_name=lambda_function.function_name
  )
  invoke.expect(ExpectedResult.object_like({
      "Payload": "200"
  }))
  ```
  The above example will by default create a CloudWatch log group that's never
  expired. If you want to configure it with custom log retention days, you need
  to specify the `logRetention` property.
  ```python
  import aws_cdk.aws_logs as logs


  stack = Stack(app, "cdk-integ-lambda-bundling")
  integ = IntegTest(app, "IntegTest",
      test_cases=[stack]
  )
  invoke = integ.assertions.invoke_function(
      function_name=lambda_function.function_name,
      log_retention=logs.RetentionDays.ONE_WEEK
  )
  ```

  In this example there is a StepFunctions state machine that is executed
  and then we assert that the result of the execution is successful.
  ```python



  test_case = IntegTest(app, "IntegTest",
      test_cases=[stack]
  )

  start = test_case.assertions.aws_api_call("StepFunctions", "startExecution", {
      "state_machine_arn": sm.state_machine_arn
  })

  describe = test_case.assertions.aws_api_call("StepFunctions", "describeExecution", {
      "execution_arn": start.get_att_string("executionArn")
  })

  describe.expect(ExpectedResult.object_like({
      "status": "SUCCEEDED"
  }))
  ```

  Sometimes it may be necessary to chain API Calls. Since each API call is its own resource, all you
  need to do is add a dependency between the calls. There is an helper method `next` that can be used.
  ```python

  integ.assertions.aws_api_call("S3", "putObject", {
      "Bucket": "my-bucket",
      "Key": "my-key",
      "Body": "helloWorld"
  }).next(integ.assertions.aws_api_call("S3", "getObject", {
      "Bucket": "my-bucket",
      "Key": "my-key"
  }))
  ```

  A common use case when performing assertions is to wait for a condition to pass. Sometimes the thing
  that you are asserting against is not done provisioning by the time the assertion runs. In these
  cases it is possible to run the assertion asynchronously by calling the `waitForAssertions()` method.
  Taking the example above of executing a StepFunctions state machine, depending on the complexity of
  the state machine, it might take a while for it to complete.
  ```python



  test_case = IntegTest(app, "IntegTest",
      test_cases=[stack]
  )

  start = test_case.assertions.aws_api_call("StepFunctions", "startExecution", {
      "state_machine_arn": sm.state_machine_arn
  })

  describe = test_case.assertions.aws_api_call("StepFunctions", "describeExecution", {
      "execution_arn": start.get_att_string("executionArn")
  }).expect(ExpectedResult.object_like({
      "status": "SUCCEEDED"
  })).wait_for_assertions()
  ```
  When you call `waitForAssertions()` the assertion provider will continuously make the `awsApiCall` until the
  `ExpectedResult` is met. You can also control the parameters for waiting, for example:
  ```python


  describe = test_case.assertions.aws_api_call("StepFunctions", "describeExecution", {
      "execution_arn": start.get_att_string("executionArn")
  }).expect(ExpectedResult.object_like({
      "status": "SUCCEEDED"
  })).wait_for_assertions(
      total_timeout=Duration.minutes(5),
      interval=Duration.seconds(15),
      backoff_rate=3
  )
  ```


pkgId: a1469076113c5a2aff74741a558d1b6f596f7effd39a16678c9ae2b4a89fe17a
name: python-aws-cdk.integ-tests-alpha
arch: src
version: 2.161.1a0
epoch: 0
release: 1
summary: CDK Integration Testing Constructs
url: https://github.com/aws/aws-cdk
rpm_license: Apache-2.0
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-cdk.integ-tests-alpha-2.161.1a0-1.src.rpm
checksum_type: sha256
description:
  <!--END STABILITY BANNER-->

  This library is meant to be used in combination with the [integ-runner](https://github.com/aws/aws-cdk/tree/main/packages/%40aws-cdk/integ-runner) CLI
  to enable users to write and execute integration tests for AWS CDK Constructs.
  An integration test should be defined as a CDK application, and
  there should be a 1:1 relationship between an integration test and a CDK application.
  So for example, in order to create an integration test called `my-function`
  we would need to create a file to contain our integration test application.
  *test/integ.my-function.ts*
  ```python
  app = App()
  stack = Stack()
  lambda_.Function(stack, "MyFunction",
      runtime=lambda_.Runtime.NODEJS_LATEST,
      handler="index.handler",
      code=lambda_.Code.from_asset(path.join(__dirname, "lambda-handler"))
  )
  ```
  This is a self contained CDK application which we could deploy by running
  ```bash
  cdk deploy --app 'node test/integ.my-function.js'
  ```
  In order to turn this into an integration test, all that is needed is to
  use the `IntegTest` construct.
  ```python


  IntegTest(app, "Integ", test_cases=[stack])
  ```
  You will notice that the `stack` is registered to the `IntegTest` as a test case.
  Each integration test can contain multiple test cases, which are just instances
  of a stack. See the [Usage](#usage) section for more details.


  Suppose you have a simple stack, that only encapsulates a Lambda function with a
  certain handler:
  ```python
  class StackUnderTest(Stack):
      def __init__(self, scope, id, *, architecture=None, description=None, env=None, stackName=None, tags=None, notificationArns=None, synthesizer=None, terminationProtection=None, analyticsReporting=None, crossRegionReferences=None, permissionsBoundary=None, suppressTemplateIndentation=None):
          super().__init__(scope, id, architecture=architecture, description=description, env=env, stackName=stackName, tags=tags, notificationArns=notificationArns, synthesizer=synthesizer, terminationProtection=terminationProtection, analyticsReporting=analyticsReporting, crossRegionReferences=crossRegionReferences, permissionsBoundary=permissionsBoundary, suppressTemplateIndentation=suppressTemplateIndentation)
          lambda_.Function(self, "Handler",
              runtime=lambda_.Runtime.NODEJS_LATEST,
              handler="index.handler",
              code=lambda_.Code.from_asset(path.join(__dirname, "lambda-handler")),
              architecture=architecture
          )
  ```
  You may want to test this stack under different conditions. For example, we want
  this stack to be deployed correctly, regardless of the architecture we choose
  for the Lambda function. In particular, it should work for both `ARM_64` and
  `X86_64`. So you can create an `IntegTestCase` that exercises both scenarios:
  ```python
  class StackUnderTest(Stack):
      def __init__(self, scope, id, *, architecture=None, description=None, env=None, stackName=None, tags=None, notificationArns=None, synthesizer=None, terminationProtection=None, analyticsReporting=None, crossRegionReferences=None, permissionsBoundary=None, suppressTemplateIndentation=None):
          super().__init__(scope, id, architecture=architecture, description=description, env=env, stackName=stackName, tags=tags, notificationArns=notificationArns, synthesizer=synthesizer, terminationProtection=terminationProtection, analyticsReporting=analyticsReporting, crossRegionReferences=crossRegionReferences, permissionsBoundary=permissionsBoundary, suppressTemplateIndentation=suppressTemplateIndentation)
          lambda_.Function(self, "Handler",
              runtime=lambda_.Runtime.NODEJS_LATEST,
              handler="index.handler",
              code=lambda_.Code.from_asset(path.join(__dirname, "lambda-handler")),
              architecture=architecture
          )

  app = App()
  IntegTest(app, "DifferentArchitectures",
      test_cases=[
          StackUnderTest(app, "Stack1",
              architecture=lambda_.Architecture.ARM_64
          ),
          StackUnderTest(app, "Stack2",
              architecture=lambda_.Architecture.X86_64
          )
      ]
  )
  ```
  This is all the instruction you need for the integration test runner to know
  which stacks to synthesize, deploy and destroy. But you may also need to
  customize the behavior of the runner by changing its parameters. For example:
  ```python
  app = App()
  stack_under_test = Stack(app, "StackUnderTest")
  stack = Stack(app, "stack")
  test_case = IntegTest(app, "CustomizedDeploymentWorkflow",
      test_cases=[stack_under_test],
      diff_assets=True,
      stack_update_workflow=True,
      cdk_command_options=CdkCommands(
          deploy=DeployCommand(
              args=DeployOptions(
                  require_approval=RequireApproval.NEVER,
                  json=True
              )
          ),
          destroy=DestroyCommand(
              args=DestroyOptions(
                  force=True
              )
          )
      )
  )
  ```

  In the majority of cases an integration test will contain a single `IntegTestCase`.
  By default when you create an `IntegTest` an `IntegTestCase` is created for you
  and all of your test cases are registered to this `IntegTestCase`. The `IntegTestCase`
  and `IntegTestCaseStack` constructs are only needed when it is necessary to
  defined different options for individual test cases.
  For example, you might want to have one test case where `diffAssets` is enabled.
  ```python


  test_case_with_assets = IntegTestCaseStack(app, "TestCaseAssets",
      diff_assets=True
  )
  IntegTest(app, "Integ", test_cases=[stack_under_test, test_case_with_assets])
  ```

  This library also provides a utility to make assertions against the infrastructure that the integration test deploys.
  There are two main scenarios in which assertions are created.
  * Part of an integration test using `integ-runner`
  In this case you would create an integration test using the `IntegTest` construct and then make assertions using the `assert` property.
  You should **not** utilize the assertion constructs directly, but should instead use the `methods` on `IntegTest.assertions`.
  ```python


  integ = IntegTest(app, "Integ", test_cases=[stack])
  integ.assertions.aws_api_call("S3", "getObject")
  ```
  By default an assertions stack is automatically generated for you. You may however provide your own stack to use.
  ```python



  integ = IntegTest(app, "Integ", test_cases=[stack], assertion_stack=assertion_stack)
  integ.assertions.aws_api_call("S3", "getObject")
  ```
  * Part of a  normal CDK deployment
  In this case you may be using assertions as part of a normal CDK deployment in order to make an assertion on the infrastructure
  before the deployment is considered successful. In this case you can utilize the assertions constructs directly.
  ```python

  AwsApiCall(my_app_stack, "GetObject",
      service="S3",
      api="getObject"
  )
  ```

  Assertions are created by using the `DeployAssert` construct. This construct creates it's own `Stack` separate from
  any stacks that you create as part of your integration tests. This `Stack` is treated differently from other stacks
  by the `integ-runner` tool. For example, this stack will not be diffed by the `integ-runner`.
  `DeployAssert` also provides utilities to register your own assertions.
  ```python



  integ = IntegTest(app, "Integ", test_cases=[stack])
  integ.assertions.expect("CustomAssertion",
      ExpectedResult.object_like({"foo": "bar"}),
      ActualResult.from_custom_resource(my_custom_resource, "data"))
  ```
  In the above example an assertion is created that will trigger a user defined `CustomResource`
  and assert that the `data` attribute is equal to `{ foo: 'bar' }`.

  A common method to retrieve the "actual" results to compare with what is expected is to make an
  API call to receive some data. This library does this by utilizing CloudFormation custom resources
  which means that CloudFormation will call out to a Lambda Function which will
  make the API call.

  Using the `HttpApiCall` will use the
  [node-fetch](https://github.com/node-fetch/node-fetch) JavaScript library to
  make the HTTP call.
  This can be done by using the class directory (in the case of a normal deployment):
  ```python

  HttpApiCall(stack, "MyAsssertion",
      url="https://example-api.com/abc"
  )
  ```
  Or by using the `httpApiCall` method on `DeployAssert` (when writing integration tests):
  ```python


  integ = IntegTest(app, "Integ",
      test_cases=[stack]
  )
  integ.assertions.http_api_call("https://example-api.com/abc")
  ```

  Using the `AwsApiCall` construct will use the AWS JavaScript SDK to make the API call.
  This can be done by using the class directory (in the case of a normal deployment):
  ```python

  AwsApiCall(stack, "MyAssertion",
      service="SQS",
      api="receiveMessage",
      parameters={
          "QueueUrl": "url"
      }
  )
  ```
  Or by using the `awsApiCall` method on `DeployAssert` (when writing integration tests):
  ```python


  integ = IntegTest(app, "Integ",
      test_cases=[stack]
  )
  integ.assertions.aws_api_call("SQS", "receiveMessage", {
      "QueueUrl": "url"
  })
  ```
  You must specify the `service` and the `api` when using The `AwsApiCall` construct.
  The `service` is the name of an AWS service, in one of the following forms:
  * An AWS SDK for JavaScript v3 package name (`@aws-sdk/client-api-gateway`)
  * An AWS SDK for JavaScript v3 client name (`api-gateway`)
  * An AWS SDK for JavaScript v2 constructor name (`APIGateway`)
  * A lowercase AWS SDK for JavaScript v2 constructor name (`apigateway`)
  The `api` is the name of an AWS API call, in one of the following forms:
  * An API call name as found in the API Reference documentation (`GetObject`)
  * The API call name starting with a lowercase letter (`getObject`)
  * The AWS SDK for JavaScript v3 command class name (`GetObjectCommand`)
  By default, the `AwsApiCall` construct will automatically add the correct IAM policies
  to allow the Lambda function to make the API call. It does this based on the `service`
  and `api` that is provided. In the above example the service is `SQS` and the api is
  `receiveMessage` so it will create a policy with `Action: 'sqs:ReceiveMessage`.
  There are some cases where the permissions do not exactly match the service/api call, for
  example the S3 `listObjectsV2` api. In these cases it is possible to add the correct policy
  by accessing the `provider` object.
  ```python



  api_call = integ.assertions.aws_api_call("S3", "listObjectsV2", {
      "Bucket": "mybucket"
  })
  api_call.provider.add_to_role_policy({
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:ListBucket"],
      "Resource": ["*"]
  })
  ```
  Note that addToRolePolicy() uses direct IAM JSON policy blobs, not a iam.PolicyStatement
  object like you will see in the rest of the CDK.

  This library currently provides the ability to assert that two values are equal
  to one another by utilizing the `EqualsAssertion` class. This utilizes a Lambda
  backed `CustomResource` which in tern uses the [Match](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.assertions.Match.html) utility from the
  [@aws-cdk/assertions](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.assertions-readme.html) library.
  ```python




  integ = IntegTest(app, "Integ",
      test_cases=[stack]
  )
  integ.assertions.invoke_function(
      function_name=fn.function_name,
      invocation_type=InvocationType.EVENT,
      payload=JSON.stringify({"status": "OK"})
  )
  message = integ.assertions.aws_api_call("SQS", "receiveMessage", {
      "QueueUrl": queue.queue_url,
      "WaitTimeSeconds": 20
  })
  message.assert_at_path("Messages.0.Body", ExpectedResult.object_like({
      "request_context": {
          "condition": "Success"
      },
      "request_payload": {
          "status": "OK"
      },
      "response_context": {
          "status_code": 200
      },
      "response_payload": "success"
  }))
  ```

  `integ-tests` also provides a `Match` utility similar to the `@aws-cdk/assertions` module. `Match`
  can be used to construct the `ExpectedResult`. While the utility is similar, only a subset of methods are currently available on the `Match` utility of this module: `arrayWith`, `objectLike`, `stringLikeRegexp` and `serializedJson`.
  ```python

  message.expect(ExpectedResult.object_like({
      "Messages": Match.array_with([{
          "Payload": Match.serialized_json({"key": "value"})
      }, {
          "Body": {
              "Values": Match.array_with([{"Asdf": 3}]),
              "Message": Match.string_like_regexp("message")
          }
      }
      ])
  }))
  ```


  In this example there is a Lambda Function that is invoked and
  we assert that the payload that is returned is equal to '200'.
  ```python


  stack = Stack(app, "cdk-integ-lambda-bundling")
  integ = IntegTest(app, "IntegTest",
      test_cases=[stack]
  )
  invoke = integ.assertions.invoke_function(
      function_name=lambda_function.function_name
  )
  invoke.expect(ExpectedResult.object_like({
      "Payload": "200"
  }))
  ```
  The above example will by default create a CloudWatch log group that's never
  expired. If you want to configure it with custom log retention days, you need
  to specify the `logRetention` property.
  ```python
  import aws_cdk.aws_logs as logs


  stack = Stack(app, "cdk-integ-lambda-bundling")
  integ = IntegTest(app, "IntegTest",
      test_cases=[stack]
  )
  invoke = integ.assertions.invoke_function(
      function_name=lambda_function.function_name,
      log_retention=logs.RetentionDays.ONE_WEEK
  )
  ```

  In this example there is a StepFunctions state machine that is executed
  and then we assert that the result of the execution is successful.
  ```python



  test_case = IntegTest(app, "IntegTest",
      test_cases=[stack]
  )

  start = test_case.assertions.aws_api_call("StepFunctions", "startExecution", {
      "state_machine_arn": sm.state_machine_arn
  })

  describe = test_case.assertions.aws_api_call("StepFunctions", "describeExecution", {
      "execution_arn": start.get_att_string("executionArn")
  })

  describe.expect(ExpectedResult.object_like({
      "status": "SUCCEEDED"
  }))
  ```

  Sometimes it may be necessary to chain API Calls. Since each API call is its own resource, all you
  need to do is add a dependency between the calls. There is an helper method `next` that can be used.
  ```python

  integ.assertions.aws_api_call("S3", "putObject", {
      "Bucket": "my-bucket",
      "Key": "my-key",
      "Body": "helloWorld"
  }).next(integ.assertions.aws_api_call("S3", "getObject", {
      "Bucket": "my-bucket",
      "Key": "my-key"
  }))
  ```

  A common use case when performing assertions is to wait for a condition to pass. Sometimes the thing
  that you are asserting against is not done provisioning by the time the assertion runs. In these
  cases it is possible to run the assertion asynchronously by calling the `waitForAssertions()` method.
  Taking the example above of executing a StepFunctions state machine, depending on the complexity of
  the state machine, it might take a while for it to complete.
  ```python



  test_case = IntegTest(app, "IntegTest",
      test_cases=[stack]
  )

  start = test_case.assertions.aws_api_call("StepFunctions", "startExecution", {
      "state_machine_arn": sm.state_machine_arn
  })

  describe = test_case.assertions.aws_api_call("StepFunctions", "describeExecution", {
      "execution_arn": start.get_att_string("executionArn")
  }).expect(ExpectedResult.object_like({
      "status": "SUCCEEDED"
  })).wait_for_assertions()
  ```
  When you call `waitForAssertions()` the assertion provider will continuously make the `awsApiCall` until the
  `ExpectedResult` is met. You can also control the parameters for waiting, for example:
  ```python


  describe = test_case.assertions.aws_api_call("StepFunctions", "describeExecution", {
      "execution_arn": start.get_att_string("executionArn")
  }).expect(ExpectedResult.object_like({
      "status": "SUCCEEDED"
  })).wait_for_assertions(
      total_timeout=Duration.minutes(5),
      interval=Duration.seconds(15),
      backoff_rate=3
  )
  ```


pkgId: 0b0e589cf1184d1c3aa35c8972d1adb7f39f0f16248539c5895045058b06a6b9
name: python-aws-cdk.integ-tests-alpha
arch: src
version: 2.167.0a0
epoch: 0
release: 1
summary: CDK Integration Testing Constructs
url: https://github.com/aws/aws-cdk
rpm_license: Apache-2.0
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-cdk.integ-tests-alpha-2.167.0a0-1.src.rpm
checksum_type: sha256
description:
  <!--END STABILITY BANNER-->

  This library is meant to be used in combination with the [integ-runner](https://github.com/aws/aws-cdk/tree/main/packages/%40aws-cdk/integ-runner) CLI
  to enable users to write and execute integration tests for AWS CDK Constructs.
  An integration test should be defined as a CDK application, and
  there should be a 1:1 relationship between an integration test and a CDK application.
  So for example, in order to create an integration test called `my-function`
  we would need to create a file to contain our integration test application.
  *test/integ.my-function.ts*
  ```python
  app = App()
  stack = Stack()
  lambda_.Function(stack, "MyFunction",
      runtime=lambda_.Runtime.NODEJS_LATEST,
      handler="index.handler",
      code=lambda_.Code.from_asset(path.join(__dirname, "lambda-handler"))
  )
  ```
  This is a self contained CDK application which we could deploy by running
  ```bash
  cdk deploy --app 'node test/integ.my-function.js'
  ```
  In order to turn this into an integration test, all that is needed is to
  use the `IntegTest` construct.
  ```python


  IntegTest(app, "Integ", test_cases=[stack])
  ```
  You will notice that the `stack` is registered to the `IntegTest` as a test case.
  Each integration test can contain multiple test cases, which are just instances
  of a stack. See the [Usage](#usage) section for more details.


  Suppose you have a simple stack, that only encapsulates a Lambda function with a
  certain handler:
  ```python
  class StackUnderTest(Stack):
      def __init__(self, scope, id, *, architecture=None, description=None, env=None, stackName=None, tags=None, notificationArns=None, synthesizer=None, terminationProtection=None, analyticsReporting=None, crossRegionReferences=None, permissionsBoundary=None, suppressTemplateIndentation=None):
          super().__init__(scope, id, architecture=architecture, description=description, env=env, stackName=stackName, tags=tags, notificationArns=notificationArns, synthesizer=synthesizer, terminationProtection=terminationProtection, analyticsReporting=analyticsReporting, crossRegionReferences=crossRegionReferences, permissionsBoundary=permissionsBoundary, suppressTemplateIndentation=suppressTemplateIndentation)
          lambda_.Function(self, "Handler",
              runtime=lambda_.Runtime.NODEJS_LATEST,
              handler="index.handler",
              code=lambda_.Code.from_asset(path.join(__dirname, "lambda-handler")),
              architecture=architecture
          )
  ```
  You may want to test this stack under different conditions. For example, we want
  this stack to be deployed correctly, regardless of the architecture we choose
  for the Lambda function. In particular, it should work for both `ARM_64` and
  `X86_64`. So you can create an `IntegTestCase` that exercises both scenarios:
  ```python
  class StackUnderTest(Stack):
      def __init__(self, scope, id, *, architecture=None, description=None, env=None, stackName=None, tags=None, notificationArns=None, synthesizer=None, terminationProtection=None, analyticsReporting=None, crossRegionReferences=None, permissionsBoundary=None, suppressTemplateIndentation=None):
          super().__init__(scope, id, architecture=architecture, description=description, env=env, stackName=stackName, tags=tags, notificationArns=notificationArns, synthesizer=synthesizer, terminationProtection=terminationProtection, analyticsReporting=analyticsReporting, crossRegionReferences=crossRegionReferences, permissionsBoundary=permissionsBoundary, suppressTemplateIndentation=suppressTemplateIndentation)
          lambda_.Function(self, "Handler",
              runtime=lambda_.Runtime.NODEJS_LATEST,
              handler="index.handler",
              code=lambda_.Code.from_asset(path.join(__dirname, "lambda-handler")),
              architecture=architecture
          )

  app = App()
  IntegTest(app, "DifferentArchitectures",
      test_cases=[
          StackUnderTest(app, "Stack1",
              architecture=lambda_.Architecture.ARM_64
          ),
          StackUnderTest(app, "Stack2",
              architecture=lambda_.Architecture.X86_64
          )
      ]
  )
  ```
  This is all the instruction you need for the integration test runner to know
  which stacks to synthesize, deploy and destroy. But you may also need to
  customize the behavior of the runner by changing its parameters. For example:
  ```python
  app = App()
  stack_under_test = Stack(app, "StackUnderTest")
  stack = Stack(app, "stack")
  test_case = IntegTest(app, "CustomizedDeploymentWorkflow",
      test_cases=[stack_under_test],
      diff_assets=True,
      stack_update_workflow=True,
      cdk_command_options=CdkCommands(
          deploy=DeployCommand(
              args=DeployOptions(
                  require_approval=RequireApproval.NEVER,
                  json=True
              )
          ),
          destroy=DestroyCommand(
              args=DestroyOptions(
                  force=True
              )
          )
      )
  )
  ```

  In the majority of cases an integration test will contain a single `IntegTestCase`.
  By default when you create an `IntegTest` an `IntegTestCase` is created for you
  and all of your test cases are registered to this `IntegTestCase`. The `IntegTestCase`
  and `IntegTestCaseStack` constructs are only needed when it is necessary to
  defined different options for individual test cases.
  For example, you might want to have one test case where `diffAssets` is enabled.
  ```python


  test_case_with_assets = IntegTestCaseStack(app, "TestCaseAssets",
      diff_assets=True
  )
  IntegTest(app, "Integ", test_cases=[stack_under_test, test_case_with_assets])
  ```

  This library also provides a utility to make assertions against the infrastructure that the integration test deploys.
  There are two main scenarios in which assertions are created.
  * Part of an integration test using `integ-runner`
  In this case you would create an integration test using the `IntegTest` construct and then make assertions using the `assert` property.
  You should **not** utilize the assertion constructs directly, but should instead use the `methods` on `IntegTest.assertions`.
  ```python


  integ = IntegTest(app, "Integ", test_cases=[stack])
  integ.assertions.aws_api_call("S3", "getObject")
  ```
  By default an assertions stack is automatically generated for you. You may however provide your own stack to use.
  ```python



  integ = IntegTest(app, "Integ", test_cases=[stack], assertion_stack=assertion_stack)
  integ.assertions.aws_api_call("S3", "getObject")
  ```
  * Part of a  normal CDK deployment
  In this case you may be using assertions as part of a normal CDK deployment in order to make an assertion on the infrastructure
  before the deployment is considered successful. In this case you can utilize the assertions constructs directly.
  ```python

  AwsApiCall(my_app_stack, "GetObject",
      service="S3",
      api="getObject"
  )
  ```

  Assertions are created by using the `DeployAssert` construct. This construct creates it's own `Stack` separate from
  any stacks that you create as part of your integration tests. This `Stack` is treated differently from other stacks
  by the `integ-runner` tool. For example, this stack will not be diffed by the `integ-runner`.
  `DeployAssert` also provides utilities to register your own assertions.
  ```python



  integ = IntegTest(app, "Integ", test_cases=[stack])
  integ.assertions.expect("CustomAssertion",
      ExpectedResult.object_like({"foo": "bar"}),
      ActualResult.from_custom_resource(my_custom_resource, "data"))
  ```
  In the above example an assertion is created that will trigger a user defined `CustomResource`
  and assert that the `data` attribute is equal to `{ foo: 'bar' }`.

  A common method to retrieve the "actual" results to compare with what is expected is to make an
  API call to receive some data. This library does this by utilizing CloudFormation custom resources
  which means that CloudFormation will call out to a Lambda Function which will
  make the API call.

  Using the `HttpApiCall` will use the
  [node-fetch](https://github.com/node-fetch/node-fetch) JavaScript library to
  make the HTTP call.
  This can be done by using the class directory (in the case of a normal deployment):
  ```python

  HttpApiCall(stack, "MyAsssertion",
      url="https://example-api.com/abc"
  )
  ```
  Or by using the `httpApiCall` method on `DeployAssert` (when writing integration tests):
  ```python


  integ = IntegTest(app, "Integ",
      test_cases=[stack]
  )
  integ.assertions.http_api_call("https://example-api.com/abc")
  ```

  Using the `AwsApiCall` construct will use the AWS JavaScript SDK to make the API call.
  This can be done by using the class directory (in the case of a normal deployment):
  ```python

  AwsApiCall(stack, "MyAssertion",
      service="SQS",
      api="receiveMessage",
      parameters={
          "QueueUrl": "url"
      }
  )
  ```
  Or by using the `awsApiCall` method on `DeployAssert` (when writing integration tests):
  ```python


  integ = IntegTest(app, "Integ",
      test_cases=[stack]
  )
  integ.assertions.aws_api_call("SQS", "receiveMessage", {
      "QueueUrl": "url"
  })
  ```
  You must specify the `service` and the `api` when using The `AwsApiCall` construct.
  The `service` is the name of an AWS service, in one of the following forms:
  * An AWS SDK for JavaScript v3 package name (`@aws-sdk/client-api-gateway`)
  * An AWS SDK for JavaScript v3 client name (`api-gateway`)
  * An AWS SDK for JavaScript v2 constructor name (`APIGateway`)
  * A lowercase AWS SDK for JavaScript v2 constructor name (`apigateway`)
  The `api` is the name of an AWS API call, in one of the following forms:
  * An API call name as found in the API Reference documentation (`GetObject`)
  * The API call name starting with a lowercase letter (`getObject`)
  * The AWS SDK for JavaScript v3 command class name (`GetObjectCommand`)
  By default, the `AwsApiCall` construct will automatically add the correct IAM policies
  to allow the Lambda function to make the API call. It does this based on the `service`
  and `api` that is provided. In the above example the service is `SQS` and the api is
  `receiveMessage` so it will create a policy with `Action: 'sqs:ReceiveMessage`.
  There are some cases where the permissions do not exactly match the service/api call, for
  example the S3 `listObjectsV2` api. In these cases it is possible to add the correct policy
  by accessing the `provider` object.
  ```python



  api_call = integ.assertions.aws_api_call("S3", "listObjectsV2", {
      "Bucket": "mybucket"
  })
  api_call.provider.add_to_role_policy({
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:ListBucket"],
      "Resource": ["*"]
  })
  ```
  Note that addToRolePolicy() uses direct IAM JSON policy blobs, not a iam.PolicyStatement
  object like you will see in the rest of the CDK.

  This library currently provides the ability to assert that two values are equal
  to one another by utilizing the `EqualsAssertion` class. This utilizes a Lambda
  backed `CustomResource` which in tern uses the [Match](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.assertions.Match.html) utility from the
  [@aws-cdk/assertions](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.assertions-readme.html) library.
  ```python




  integ = IntegTest(app, "Integ",
      test_cases=[stack]
  )
  integ.assertions.invoke_function(
      function_name=fn.function_name,
      invocation_type=InvocationType.EVENT,
      payload=JSON.stringify({"status": "OK"})
  )
  message = integ.assertions.aws_api_call("SQS", "receiveMessage", {
      "QueueUrl": queue.queue_url,
      "WaitTimeSeconds": 20
  })
  message.assert_at_path("Messages.0.Body", ExpectedResult.object_like({
      "request_context": {
          "condition": "Success"
      },
      "request_payload": {
          "status": "OK"
      },
      "response_context": {
          "status_code": 200
      },
      "response_payload": "success"
  }))
  ```

  `integ-tests` also provides a `Match` utility similar to the `@aws-cdk/assertions` module. `Match`
  can be used to construct the `ExpectedResult`. While the utility is similar, only a subset of methods are currently available on the `Match` utility of this module: `arrayWith`, `objectLike`, `stringLikeRegexp` and `serializedJson`.
  ```python

  message.expect(ExpectedResult.object_like({
      "Messages": Match.array_with([{
          "Payload": Match.serialized_json({"key": "value"})
      }, {
          "Body": {
              "Values": Match.array_with([{"Asdf": 3}]),
              "Message": Match.string_like_regexp("message")
          }
      }
      ])
  }))
  ```


  In this example there is a Lambda Function that is invoked and
  we assert that the payload that is returned is equal to '200'.
  ```python


  stack = Stack(app, "cdk-integ-lambda-bundling")
  integ = IntegTest(app, "IntegTest",
      test_cases=[stack]
  )
  invoke = integ.assertions.invoke_function(
      function_name=lambda_function.function_name
  )
  invoke.expect(ExpectedResult.object_like({
      "Payload": "200"
  }))
  ```
  The above example will by default create a CloudWatch log group that's never
  expired. If you want to configure it with custom log retention days, you need
  to specify the `logRetention` property.
  ```python
  import aws_cdk.aws_logs as logs


  stack = Stack(app, "cdk-integ-lambda-bundling")
  integ = IntegTest(app, "IntegTest",
      test_cases=[stack]
  )
  invoke = integ.assertions.invoke_function(
      function_name=lambda_function.function_name,
      log_retention=logs.RetentionDays.ONE_WEEK
  )
  ```

  In this example there is a StepFunctions state machine that is executed
  and then we assert that the result of the execution is successful.
  ```python



  test_case = IntegTest(app, "IntegTest",
      test_cases=[stack]
  )

  start = test_case.assertions.aws_api_call("StepFunctions", "startExecution", {
      "state_machine_arn": sm.state_machine_arn
  })

  describe = test_case.assertions.aws_api_call("StepFunctions", "describeExecution", {
      "execution_arn": start.get_att_string("executionArn")
  })

  describe.expect(ExpectedResult.object_like({
      "status": "SUCCEEDED"
  }))
  ```

  Sometimes it may be necessary to chain API Calls. Since each API call is its own resource, all you
  need to do is add a dependency between the calls. There is an helper method `next` that can be used.
  ```python

  integ.assertions.aws_api_call("S3", "putObject", {
      "Bucket": "amzn-s3-demo-bucket",
      "Key": "my-key",
      "Body": "helloWorld"
  }).next(integ.assertions.aws_api_call("S3", "getObject", {
      "Bucket": "amzn-s3-demo-bucket",
      "Key": "my-key"
  }))
  ```

  A common use case when performing assertions is to wait for a condition to pass. Sometimes the thing
  that you are asserting against is not done provisioning by the time the assertion runs. In these
  cases it is possible to run the assertion asynchronously by calling the `waitForAssertions()` method.
  Taking the example above of executing a StepFunctions state machine, depending on the complexity of
  the state machine, it might take a while for it to complete.
  ```python



  test_case = IntegTest(app, "IntegTest",
      test_cases=[stack]
  )

  start = test_case.assertions.aws_api_call("StepFunctions", "startExecution", {
      "state_machine_arn": sm.state_machine_arn
  })

  describe = test_case.assertions.aws_api_call("StepFunctions", "describeExecution", {
      "execution_arn": start.get_att_string("executionArn")
  }).expect(ExpectedResult.object_like({
      "status": "SUCCEEDED"
  })).wait_for_assertions()
  ```
  When you call `waitForAssertions()` the assertion provider will continuously make the `awsApiCall` until the
  `ExpectedResult` is met. You can also control the parameters for waiting, for example:
  ```python


  describe = test_case.assertions.aws_api_call("StepFunctions", "describeExecution", {
      "execution_arn": start.get_att_string("executionArn")
  }).expect(ExpectedResult.object_like({
      "status": "SUCCEEDED"
  })).wait_for_assertions(
      total_timeout=Duration.minutes(5),
      interval=Duration.seconds(15),
      backoff_rate=3
  )
  ```


pkgId: 3c005fde8a0dc382b525259fbcc49b6b1f6dddfb976d66e3d5080f18f9f3b2e7
name: python-aws-cdk.integ-tests-alpha
arch: src
version: 2.171.0a0
epoch: 0
release: 1
summary: CDK Integration Testing Constructs
url: https://github.com/aws/aws-cdk
rpm_license: Apache-2.0
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-cdk.integ-tests-alpha-2.171.0a0-1.src.rpm
checksum_type: sha256
description:
  <!--END STABILITY BANNER-->

  This library is meant to be used in combination with the [integ-runner](https://github.com/aws/aws-cdk/tree/main/packages/%40aws-cdk/integ-runner) CLI
  to enable users to write and execute integration tests for AWS CDK Constructs.
  An integration test should be defined as a CDK application, and
  there should be a 1:1 relationship between an integration test and a CDK application.
  So for example, in order to create an integration test called `my-function`
  we would need to create a file to contain our integration test application.
  *test/integ.my-function.ts*
  ```python
  app = App()
  stack = Stack()
  lambda_.Function(stack, "MyFunction",
      runtime=lambda_.Runtime.NODEJS_LATEST,
      handler="index.handler",
      code=lambda_.Code.from_asset(path.join(__dirname, "lambda-handler"))
  )
  ```
  This is a self contained CDK application which we could deploy by running
  ```bash
  cdk deploy --app 'node test/integ.my-function.js'
  ```
  In order to turn this into an integration test, all that is needed is to
  use the `IntegTest` construct.
  ```python


  IntegTest(app, "Integ", test_cases=[stack])
  ```
  You will notice that the `stack` is registered to the `IntegTest` as a test case.
  Each integration test can contain multiple test cases, which are just instances
  of a stack. See the [Usage](#usage) section for more details.


  Suppose you have a simple stack, that only encapsulates a Lambda function with a
  certain handler:
  ```python
  class StackUnderTest(Stack):
      def __init__(self, scope, id, *, architecture=None, description=None, env=None, stackName=None, tags=None, notificationArns=None, synthesizer=None, terminationProtection=None, analyticsReporting=None, crossRegionReferences=None, permissionsBoundary=None, suppressTemplateIndentation=None):
          super().__init__(scope, id, architecture=architecture, description=description, env=env, stackName=stackName, tags=tags, notificationArns=notificationArns, synthesizer=synthesizer, terminationProtection=terminationProtection, analyticsReporting=analyticsReporting, crossRegionReferences=crossRegionReferences, permissionsBoundary=permissionsBoundary, suppressTemplateIndentation=suppressTemplateIndentation)
          lambda_.Function(self, "Handler",
              runtime=lambda_.Runtime.NODEJS_LATEST,
              handler="index.handler",
              code=lambda_.Code.from_asset(path.join(__dirname, "lambda-handler")),
              architecture=architecture
          )
  ```
  You may want to test this stack under different conditions. For example, we want
  this stack to be deployed correctly, regardless of the architecture we choose
  for the Lambda function. In particular, it should work for both `ARM_64` and
  `X86_64`. So you can create an `IntegTestCase` that exercises both scenarios:
  ```python
  class StackUnderTest(Stack):
      def __init__(self, scope, id, *, architecture=None, description=None, env=None, stackName=None, tags=None, notificationArns=None, synthesizer=None, terminationProtection=None, analyticsReporting=None, crossRegionReferences=None, permissionsBoundary=None, suppressTemplateIndentation=None):
          super().__init__(scope, id, architecture=architecture, description=description, env=env, stackName=stackName, tags=tags, notificationArns=notificationArns, synthesizer=synthesizer, terminationProtection=terminationProtection, analyticsReporting=analyticsReporting, crossRegionReferences=crossRegionReferences, permissionsBoundary=permissionsBoundary, suppressTemplateIndentation=suppressTemplateIndentation)
          lambda_.Function(self, "Handler",
              runtime=lambda_.Runtime.NODEJS_LATEST,
              handler="index.handler",
              code=lambda_.Code.from_asset(path.join(__dirname, "lambda-handler")),
              architecture=architecture
          )

  app = App()
  IntegTest(app, "DifferentArchitectures",
      test_cases=[
          StackUnderTest(app, "Stack1",
              architecture=lambda_.Architecture.ARM_64
          ),
          StackUnderTest(app, "Stack2",
              architecture=lambda_.Architecture.X86_64
          )
      ]
  )
  ```
  This is all the instruction you need for the integration test runner to know
  which stacks to synthesize, deploy and destroy. But you may also need to
  customize the behavior of the runner by changing its parameters. For example:
  ```python
  app = App()
  stack_under_test = Stack(app, "StackUnderTest")
  stack = Stack(app, "stack")
  test_case = IntegTest(app, "CustomizedDeploymentWorkflow",
      test_cases=[stack_under_test],
      diff_assets=True,
      stack_update_workflow=True,
      cdk_command_options=CdkCommands(
          deploy=DeployCommand(
              args=DeployOptions(
                  require_approval=RequireApproval.NEVER,
                  json=True
              )
          ),
          destroy=DestroyCommand(
              args=DestroyOptions(
                  force=True
              )
          )
      )
  )
  ```

  In the majority of cases an integration test will contain a single `IntegTestCase`.
  By default when you create an `IntegTest` an `IntegTestCase` is created for you
  and all of your test cases are registered to this `IntegTestCase`. The `IntegTestCase`
  and `IntegTestCaseStack` constructs are only needed when it is necessary to
  defined different options for individual test cases.
  For example, you might want to have one test case where `diffAssets` is enabled.
  ```python


  test_case_with_assets = IntegTestCaseStack(app, "TestCaseAssets",
      diff_assets=True
  )
  IntegTest(app, "Integ", test_cases=[stack_under_test, test_case_with_assets])
  ```

  This library also provides a utility to make assertions against the infrastructure that the integration test deploys.
  There are two main scenarios in which assertions are created.
  * Part of an integration test using `integ-runner`
  In this case you would create an integration test using the `IntegTest` construct and then make assertions using the `assert` property.
  You should **not** utilize the assertion constructs directly, but should instead use the `methods` on `IntegTest.assertions`.
  ```python


  integ = IntegTest(app, "Integ", test_cases=[stack])
  integ.assertions.aws_api_call("S3", "getObject")
  ```
  By default an assertions stack is automatically generated for you. You may however provide your own stack to use.
  ```python



  integ = IntegTest(app, "Integ", test_cases=[stack], assertion_stack=assertion_stack)
  integ.assertions.aws_api_call("S3", "getObject")
  ```
  * Part of a  normal CDK deployment
  In this case you may be using assertions as part of a normal CDK deployment in order to make an assertion on the infrastructure
  before the deployment is considered successful. In this case you can utilize the assertions constructs directly.
  ```python

  AwsApiCall(my_app_stack, "GetObject",
      service="S3",
      api="getObject"
  )
  ```

  Assertions are created by using the `DeployAssert` construct. This construct creates it's own `Stack` separate from
  any stacks that you create as part of your integration tests. This `Stack` is treated differently from other stacks
  by the `integ-runner` tool. For example, this stack will not be diffed by the `integ-runner`.
  `DeployAssert` also provides utilities to register your own assertions.
  ```python



  integ = IntegTest(app, "Integ", test_cases=[stack])
  integ.assertions.expect("CustomAssertion",
      ExpectedResult.object_like({"foo": "bar"}),
      ActualResult.from_custom_resource(my_custom_resource, "data"))
  ```
  In the above example an assertion is created that will trigger a user defined `CustomResource`
  and assert that the `data` attribute is equal to `{ foo: 'bar' }`.

  A common method to retrieve the "actual" results to compare with what is expected is to make an
  API call to receive some data. This library does this by utilizing CloudFormation custom resources
  which means that CloudFormation will call out to a Lambda Function which will
  make the API call.

  Using the `HttpApiCall` will use the
  [node-fetch](https://github.com/node-fetch/node-fetch) JavaScript library to
  make the HTTP call.
  This can be done by using the class directory (in the case of a normal deployment):
  ```python

  HttpApiCall(stack, "MyAsssertion",
      url="https://example-api.com/abc"
  )
  ```
  Or by using the `httpApiCall` method on `DeployAssert` (when writing integration tests):
  ```python


  integ = IntegTest(app, "Integ",
      test_cases=[stack]
  )
  integ.assertions.http_api_call("https://example-api.com/abc")
  ```

  Using the `AwsApiCall` construct will use the AWS JavaScript SDK to make the API call.
  This can be done by using the class directory (in the case of a normal deployment):
  ```python

  AwsApiCall(stack, "MyAssertion",
      service="SQS",
      api="receiveMessage",
      parameters={
          "QueueUrl": "url"
      }
  )
  ```
  Or by using the `awsApiCall` method on `DeployAssert` (when writing integration tests):
  ```python


  integ = IntegTest(app, "Integ",
      test_cases=[stack]
  )
  integ.assertions.aws_api_call("SQS", "receiveMessage", {
      "QueueUrl": "url"
  })
  ```
  You must specify the `service` and the `api` when using The `AwsApiCall` construct.
  The `service` is the name of an AWS service, in one of the following forms:
  * An AWS SDK for JavaScript v3 package name (`@aws-sdk/client-api-gateway`)
  * An AWS SDK for JavaScript v3 client name (`api-gateway`)
  * An AWS SDK for JavaScript v2 constructor name (`APIGateway`)
  * A lowercase AWS SDK for JavaScript v2 constructor name (`apigateway`)
  The `api` is the name of an AWS API call, in one of the following forms:
  * An API call name as found in the API Reference documentation (`GetObject`)
  * The API call name starting with a lowercase letter (`getObject`)
  * The AWS SDK for JavaScript v3 command class name (`GetObjectCommand`)
  By default, the `AwsApiCall` construct will automatically add the correct IAM policies
  to allow the Lambda function to make the API call. It does this based on the `service`
  and `api` that is provided. In the above example the service is `SQS` and the api is
  `receiveMessage` so it will create a policy with `Action: 'sqs:ReceiveMessage`.
  There are some cases where the permissions do not exactly match the service/api call, for
  example the S3 `listObjectsV2` api. In these cases it is possible to add the correct policy
  by accessing the `provider` object.
  ```python



  api_call = integ.assertions.aws_api_call("S3", "listObjectsV2", {
      "Bucket": "mybucket"
  })
  api_call.provider.add_to_role_policy({
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:ListBucket"],
      "Resource": ["*"]
  })
  ```
  When executing `waitForAssertion()`, it is necessary to add an IAM policy using `waiterProvider.addToRolePolicy()`.
  Because `IApiCall` does not have a `waiterProvider` property, you need to cast it to `AwsApiCall`.
  ```python

  api_call = integ.assertions.aws_api_call("S3", "listObjectsV2", {
      "Bucket": "mybucket"
  }).wait_for_assertions()
  api_call.waiter_provider.add_to_role_policy({
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:ListBucket"],
      "Resource": ["*"]
  })
  ```
  Note that addToRolePolicy() uses direct IAM JSON policy blobs, not a iam.PolicyStatement
  object like you will see in the rest of the CDK.

  This library currently provides the ability to assert that two values are equal
  to one another by utilizing the `EqualsAssertion` class. This utilizes a Lambda
  backed `CustomResource` which in tern uses the [Match](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.assertions.Match.html) utility from the
  [@aws-cdk/assertions](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.assertions-readme.html) library.
  ```python




  integ = IntegTest(app, "Integ",
      test_cases=[stack]
  )
  integ.assertions.invoke_function(
      function_name=fn.function_name,
      invocation_type=InvocationType.EVENT,
      payload=JSON.stringify({"status": "OK"})
  )
  message = integ.assertions.aws_api_call("SQS", "receiveMessage", {
      "QueueUrl": queue.queue_url,
      "WaitTimeSeconds": 20
  })
  message.assert_at_path("Messages.0.Body", ExpectedResult.object_like({
      "request_context": {
          "condition": "Success"
      },
      "request_payload": {
          "status": "OK"
      },
      "response_context": {
          "status_code": 200
      },
      "response_payload": "success"
  }))
  ```

  `integ-tests` also provides a `Match` utility similar to the `@aws-cdk/assertions` module. `Match`
  can be used to construct the `ExpectedResult`. While the utility is similar, only a subset of methods are currently available on the `Match` utility of this module: `arrayWith`, `objectLike`, `stringLikeRegexp` and `serializedJson`.
  ```python

  message.expect(ExpectedResult.object_like({
      "Messages": Match.array_with([{
          "Payload": Match.serialized_json({"key": "value"})
      }, {
          "Body": {
              "Values": Match.array_with([{"Asdf": 3}]),
              "Message": Match.string_like_regexp("message")
          }
      }
      ])
  }))
  ```


  In this example there is a Lambda Function that is invoked and
  we assert that the payload that is returned is equal to '200'.
  ```python


  stack = Stack(app, "cdk-integ-lambda-bundling")
  integ = IntegTest(app, "IntegTest",
      test_cases=[stack]
  )
  invoke = integ.assertions.invoke_function(
      function_name=lambda_function.function_name
  )
  invoke.expect(ExpectedResult.object_like({
      "Payload": "200"
  }))
  ```
  The above example will by default create a CloudWatch log group that's never
  expired. If you want to configure it with custom log retention days, you need
  to specify the `logRetention` property.
  ```python
  import aws_cdk.aws_logs as logs


  stack = Stack(app, "cdk-integ-lambda-bundling")
  integ = IntegTest(app, "IntegTest",
      test_cases=[stack]
  )
  invoke = integ.assertions.invoke_function(
      function_name=lambda_function.function_name,
      log_retention=logs.RetentionDays.ONE_WEEK
  )
  ```

  In this example there is a StepFunctions state machine that is executed
  and then we assert that the result of the execution is successful.
  ```python



  test_case = IntegTest(app, "IntegTest",
      test_cases=[stack]
  )

  start = test_case.assertions.aws_api_call("StepFunctions", "startExecution", {
      "state_machine_arn": sm.state_machine_arn
  })

  describe = test_case.assertions.aws_api_call("StepFunctions", "describeExecution", {
      "execution_arn": start.get_att_string("executionArn")
  })

  describe.expect(ExpectedResult.object_like({
      "status": "SUCCEEDED"
  }))
  ```

  Sometimes it may be necessary to chain API Calls. Since each API call is its own resource, all you
  need to do is add a dependency between the calls. There is an helper method `next` that can be used.
  ```python

  integ.assertions.aws_api_call("S3", "putObject", {
      "Bucket": "amzn-s3-demo-bucket",
      "Key": "my-key",
      "Body": "helloWorld"
  }).next(integ.assertions.aws_api_call("S3", "getObject", {
      "Bucket": "amzn-s3-demo-bucket",
      "Key": "my-key"
  }))
  ```

  A common use case when performing assertions is to wait for a condition to pass. Sometimes the thing
  that you are asserting against is not done provisioning by the time the assertion runs. In these
  cases it is possible to run the assertion asynchronously by calling the `waitForAssertions()` method.
  Taking the example above of executing a StepFunctions state machine, depending on the complexity of
  the state machine, it might take a while for it to complete.
  ```python



  test_case = IntegTest(app, "IntegTest",
      test_cases=[stack]
  )

  start = test_case.assertions.aws_api_call("StepFunctions", "startExecution", {
      "state_machine_arn": sm.state_machine_arn
  })

  describe = test_case.assertions.aws_api_call("StepFunctions", "describeExecution", {
      "execution_arn": start.get_att_string("executionArn")
  }).expect(ExpectedResult.object_like({
      "status": "SUCCEEDED"
  })).wait_for_assertions()
  ```
  When you call `waitForAssertions()` the assertion provider will continuously make the `awsApiCall` until the
  `ExpectedResult` is met. You can also control the parameters for waiting, for example:
  ```python


  describe = test_case.assertions.aws_api_call("StepFunctions", "describeExecution", {
      "execution_arn": start.get_att_string("executionArn")
  }).expect(ExpectedResult.object_like({
      "status": "SUCCEEDED"
  })).wait_for_assertions(
      total_timeout=Duration.minutes(5),
      interval=Duration.seconds(15),
      backoff_rate=3
  )
  ```


pkgId: b6ce849bd338a524869fb4be43c4b0877c0bd2d456942be0bb0f389c92922ce4
name: python-aws-cdk.lambda-layer-kubectl-v24
arch: src
version: 2.0.242
epoch: 0
release: 1
summary: A Lambda Layer that contains kubectl v1.24
url: https://github.com/cdklabs/awscdk-asset-kubectl#readme
rpm_license: Apache-2.0
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-cdk.lambda-layer-kubectl-v24-2.0.242-1.src.rpm
checksum_type: sha256
description:
  <!--END STABILITY BANNER-->
  This module exports a single class called `KubectlV24Layer` which is a `lambda.LayerVersion` that
  bundles the [`kubectl`](https://kubernetes.io/docs/reference/kubectl/kubectl/) and the
  [`helm`](https://helm.sh/) command line.
  > * Helm Version: 3.9.4
  > * Kubectl Version: 1.24.0
  Usage:
  ```python
  // KubectlLayer bundles the 'kubectl' and 'helm' command lines
  import { KubectlV24Layer } from '@aws-cdk/lambda-layer-kubectl-v24';
  import * as lambda from 'aws-cdk-lib/aws-lambda';
  declare const fn: lambda.Function;
  const kubectl = new KubectlV24Layer(this, 'KubectlLayer');
  fn.addLayers(kubectl);
  ```
  `kubectl` will be installed under `/opt/kubectl/kubectl`, and `helm` will be installed under `/opt/helm/helm`.


pkgId: c579a6d0b3e42bd12239f950e3fd45222d15af4bc21746bf7ff14194e44ce180
name: python-aws-cdk.lambda-layer-kubectl-v25
arch: src
version: 2.0.4
epoch: 0
release: 1
summary: A Lambda Layer that contains kubectl v1.25
url: https://github.com/cdklabs/awscdk-asset-kubectl#readme
rpm_license: Apache-2.0
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-cdk.lambda-layer-kubectl-v25-2.0.4-1.src.rpm
checksum_type: sha256
description:
  <!--END STABILITY BANNER-->
  This module exports a single class called `KubectlV25Layer` which is a `lambda.LayerVersion` that
  bundles the [`kubectl`](https://kubernetes.io/docs/reference/kubectl/kubectl/) and the
  [`helm`](https://helm.sh/) command line.
  > * Helm Version: 3.11.1
  > * Kubectl Version: 1.25.0
  Usage:
  ```python
  // KubectlLayer bundles the 'kubectl' and 'helm' command lines
  import { KubectlV25Layer } from '@aws-cdk/lambda-layer-kubectl-v25';
  import * as lambda from 'aws-cdk-lib/aws-lambda';
  declare const fn: lambda.Function;
  const kubectl = new KubectlV25Layer(this, 'KubectlLayer');
  fn.addLayers(kubectl);
  ```
  `kubectl` will be installed under `/opt/kubectl/kubectl`, and `helm` will be installed under `/opt/helm/helm`.


pkgId: 76dd74d15b2ee6285c48a08e7b6b681529cbb5e53bfca3e40f7995cfce5b4e16
name: python-aws-cdk.lambda-layer-kubectl-v27
arch: src
version: 2.1.0
epoch: 0
release: 1
summary: A Lambda Layer that contains kubectl v1.27
url: https://github.com/cdklabs/awscdk-asset-kubectl#readme
rpm_license: Apache-2.0
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-cdk.lambda-layer-kubectl-v27-2.1.0-1.src.rpm
checksum_type: sha256
description:
  <!--END STABILITY BANNER-->
  This module exports a single class called `KubectlV27Layer` which is a `lambda.LayerVersion` that
  bundles the [`kubectl`](https://kubernetes.io/docs/reference/kubectl/kubectl/) and the
  [`helm`](https://helm.sh/) command line.
  > * Helm Version: 3.12.1
  > * Kubectl Version: 1.27.1
  Usage:
  ```python
  // KubectlLayer bundles the 'kubectl' and 'helm' command lines
  import { KubectlV27Layer } from '@aws-cdk/lambda-layer-kubectl-v27';
  import * as lambda from 'aws-cdk-lib/aws-lambda';
  declare const fn: lambda.Function;
  const kubectl = new KubectlV27Layer(this, 'KubectlLayer');
  fn.addLayers(kubectl);
  ```
  `kubectl` will be installed under `/opt/kubectl/kubectl`, and `helm` will be installed under `/opt/helm/helm`.


pkgId: 8d823ecf70b886df683c0a714d2c3c81037bbe4c75c446560f6f8491ed4825fd
name: python-aws-cdk.lambda-layer-kubectl-v28
arch: src
version: 2.2.0
epoch: 0
release: 1
summary: A Lambda Layer that contains kubectl v1.28
url: https://github.com/cdklabs/awscdk-asset-kubectl#readme
rpm_license: Apache-2.0
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-cdk.lambda-layer-kubectl-v28-2.2.0-1.src.rpm
checksum_type: sha256
description:
  <!--END STABILITY BANNER-->
  This module exports a single class called `KubectlV28Layer` which is a `lambda.LayerVersion` that
  bundles the [`kubectl`](https://kubernetes.io/docs/reference/kubectl/kubectl/) and the
  [`helm`](https://helm.sh/) command line.
  > * Helm Version: 3.14.0
  > * Kubectl Version: 1.28.3
  Usage:
  ```python
  // KubectlLayer bundles the 'kubectl' and 'helm' command lines
  import { KubectlV28Layer } from '@aws-cdk/lambda-layer-kubectl-v28';
  import * as lambda from 'aws-cdk-lib/aws-lambda';
  declare const fn: lambda.Function;
  const kubectl = new KubectlV28Layer(this, 'KubectlLayer');
  fn.addLayers(kubectl);
  ```
  `kubectl` will be installed under `/opt/kubectl/kubectl`, and `helm` will be installed under `/opt/helm/helm`.


pkgId: b716a46f34bcc016db2fd297d4741bebad02a4f63ef23c6f434bbc5bc29f4078
name: python-aws-cdk.lambda-layer-kubectl-v29
arch: src
version: 2.1.0
epoch: 0
release: 1
summary: A Lambda Layer that contains kubectl v1.29
url: https://github.com/cdklabs/awscdk-asset-kubectl#readme
rpm_license: Apache-2.0
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-cdk.lambda-layer-kubectl-v29-2.1.0-1.src.rpm
checksum_type: sha256
description:
  <!--END STABILITY BANNER-->
  This module exports a single class called `KubectlV29Layer` which is a `lambda.LayerVersion` that
  bundles the [`kubectl`](https://kubernetes.io/docs/reference/kubectl/kubectl/) and the
  [`helm`](https://helm.sh/) command line.
  > * Helm Version: 3.14.4
  > * Kubectl Version: 1.29.4
  Usage:
  ```python
  // KubectlLayer bundles the 'kubectl' and 'helm' command lines
  import { KubectlV29Layer } from '@aws-cdk/lambda-layer-kubectl-v29';
  import * as lambda from 'aws-cdk-lib/aws-lambda';
  declare const fn: lambda.Function;
  const kubectl = new KubectlV29Layer(this, 'KubectlLayer');
  fn.addLayers(kubectl);
  ```
  `kubectl` will be installed under `/opt/kubectl/kubectl`, and `helm` will be installed under `/opt/helm/helm`.


pkgId: 9887f736086a489e22270472950dce352fbc439d80bed4a885c3593f36b40959
name: python-aws-cdk.lambda-layer-kubectl-v30
arch: src
version: 2.0.1
epoch: 0
release: 1
summary: A Lambda Layer that contains kubectl v1.30
url: https://github.com/cdklabs/awscdk-asset-kubectl#readme
rpm_license: Apache-2.0
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-cdk.lambda-layer-kubectl-v30-2.0.1-1.src.rpm
checksum_type: sha256
description:
  <!--END STABILITY BANNER-->
  This module exports a single class called `KubectlV30Layer` which is a `lambda.LayerVersion` that
  bundles the [`kubectl`](https://kubernetes.io/docs/reference/kubectl/kubectl/) and the
  [`helm`](https://helm.sh/) command lines.
  > * Helm Version: 3.15.4
  > * Kubectl Version: 1.30.0
  Usage:
  ```python
  // KubectlLayer bundles the 'kubectl' and 'helm' command lines
  import { KubectlV30Layer } from '@aws-cdk/lambda-layer-kubectl-v30';
  import * as lambda from 'aws-cdk-lib/aws-lambda';
  declare const fn: lambda.Function;
  const kubectl = new KubectlV30Layer(this, 'KubectlLayer');
  fn.addLayers(kubectl);
  ```
  `kubectl` will be installed under `/opt/kubectl/kubectl`, and `helm` will be installed under `/opt/helm/helm`.


pkgId: 31b74597155a9e5362581274f2216c3b4d5d94f02bdf59b6df7fd5a68ececf13
name: python-aws-cidr-finder
arch: src
version: 0.6.2
epoch: 0
release: 1
summary: A CLI tool and library for finding unused CIDR blocks in AWS VPCs.
url: https://github.com/cooperwalbrun/aws-cidr-finder
rpm_license: GNU General Public License v3 (GPLv3)
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-cidr-finder-0.6.2-1.src.rpm
checksum_type: sha256
description:
  172.31.96.0/19         8192
  172.31.128.0/17       32768
  Total                 40960
  ```
  You should notice that, by default, `aws-cidr-finder` will automatically "simplify" the CIDRs
  by merging adjacent free CIDR blocks so that the resulting table shows the maximum contiguous space
  per CIDR (in other words, the resulting table has the fewest number of rows possible). This is why
  the result of the command displayed only two CIDRs: a `/19` and a `/17`.
  >Note that the first CIDR is `/19` instead of, for example, `/18`, because the `/18` CIDR would
  >mathematically have to begin at IP address `172.31.64.0`, and that IP address is already taken by a
  >subnet!
  However, we can change this "simplification" behavior by specifying the `--prefix` CLI flag:
  ```bash
  aws-cidr-finder --profile myprofile --prefix 20
  ```
  Now, the expected output should look something like this:
  ```
  Here are the available CIDR blocks in the 'Hello World' VPC (VPC CIDR block '172.31.0.0/16'):


pkgId: 717bfb49798fb96b98fe766499a0b88444d2801caa151e43d12ff6b001bf7827
name: python-aws-cloudformation
arch: src
version: 1.5.1
epoch: 0
release: 1
url: https://github.com/MacHu-GWU/aws_cloudformation-project
rpm_license: MIT
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-cloudformation-1.5.1-1.src.rpm
checksum_type: sha256
summary:
  ⭐ AWS CloudFormation deployment for human, Enable terraform plan, terraform apply styled deployment.


pkgId: e8a60e2c30a77bcdb68ee34b53d08b10e4669e21aaff475d9799d0f7e9345d21
name: python-aws-cloudformation-power-switch
arch: src
version: 1.0.5
epoch: 0
release: 1
summary: shutdown and startup AWS CloudFormation EC2 and RDS instances
url: https://github.com/binxio/aws-cloudformation-power-switch
rpm_license: BSD
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-cloudformation-power-switch-1.0.5-1.src.rpm
checksum_type: sha256
description:
  AWS CloudFormation power switch allows you to shutdown and startup all EC2, ECS, RDS and
  AutoScaling instances managed by one or more CloudFormation stacks.


  to install the power switch, type:

  ```sh
  pip install aws-cloudformation-power-switch
  ```


  to shutdown all instances managed by CloudFormation stacks starting with the name `dev`, type:
  ```sh
  cfn-power-switch --dry-run --stack-name-prefix dev on
  ```
  This will show you which EC2, RDS and AutoScaling instances will be shutdown. For Auto Scaling groups, the
  desired number of instances is set to 0. If the minimum is greater than 0, it will change the minimum setting too.


  to startup all instances managed by a CloudFormation stacks starting with the name `dev`, type:
  ```sh
  cfn-power-switch --dry-run --stack-name-prefix dev off
  ```
  This will show you which EC2, RDS and AutoScaling instances will be started. The AutoScaling desired number of
  instances will be set the maximum desired instances. Remove the `--dry-run` and it will be activated.



  To deploy the power switch as an AWS Lambda, type:

  ```sh
  git clone https://github.com/binxio/aws-cloudformation-power-switch.git
  cd aws-cloudformation-power-switch.git
  aws cloudformation deploy \
  	--capabilities CAPABILITY_IAM \
  	--stack-name aws-cloudformation-power-switch \
  	--template-file ./cloudformation/aws-cloudformation-power-switch.yaml
  ```


  install the demonstration, type:
  ```
  aws cloudformation deploy \
  	--capabilities CAPABILITY_IAM \
  	--stack-name aws-cloudformation-power-switch-demo \
  	--template-file ./cloudformation/demo-stack.yaml
  ```
  This deploy an ec2 instance, an autoscaling group and a RDS MySQL database instance, It will
  shutdown down all EC2, RDS and Auto Scaling instances managed by CloudFormation stacks starting
  with the name `dev` at 23:30 and start them backup at 7:30 in the morning.

  To manual stop all the instance, type:
  ```
  cfn-power-switch --verbose --stack-name-prefix aws-cloudformation-power-switch off
  ```
  It will take few minutes before everything is shutdown and you can restart the stack.

  to start everything back up, type:
  ```
  cfn-power-switch --verbose --stack-name-prefix aws-cloudformation-power-switch off
  ```
  It will take few minutes before everything is running again.

  Do not forget to delete the stack:
  ```
  aws cloudformation delete-stack --stack-name aws-cloudformation-power-switch-demo
  ```


  - The power switch will only start instances in `stopped` state`, and stop instances in the `available` or `running` state. If it is transitioning between states, no action is taken.
  - As CloudFormation does not place the `aws:cloudformation:` tags on RDS Aurora Clusters, we need to load all CloudFormation stacks and resources to find out whether we need to start or stop it. And listing all CloudFormation stacks is very, very slow...
  - the ECS services desired count is read from the latest  `started [0-9]+ tasks` event of that service
  - the auto scaling group desired count is set to the max when powering on.


pkgId: ac4a82b2ef3b14d3b2c5bda5489300b870d9b2a1724e5a49c881e6661018e679
name: python-aws-codeartifact-poetry
arch: src
version: 1.5.0
epoch: 0
release: 1
summary: AWS CodeArtifact Poetry CLI
url: https://github.com/lucasvieirasilva/aws-codeartifact-poetry
rpm_license: Proprietary
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-codeartifact-poetry-1.5.0-1.src.rpm
checksum_type: sha256
description:
  [![Vulnerabilities](https://sonarcloud.io/api/project_badges/measure?project=lucasvieirasilva_aws-codeartifact-poetry&metric=vulnerabilities)](https://sonarcloud.io/summary/new_code?id=lucasvieirasilva_aws-codeartifact-poetry)
  [![Bugs](https://sonarcloud.io/api/project_badges/measure?project=lucasvieirasilva_aws-codeartifact-poetry&metric=bugs)](https://sonarcloud.io/summary/new_code?id=lucasvieirasilva_aws-codeartifact-poetry)
  [![Code Smells](https://sonarcloud.io/api/project_badges/measure?project=lucasvieirasilva_aws-codeartifact-poetry&metric=code_smells)](https://sonarcloud.io/summary/new_code?id=lucasvieirasilva_aws-codeartifact-poetry)
  [![Technical Debt](https://sonarcloud.io/api/project_badges/measure?project=lucasvieirasilva_aws-codeartifact-poetry&metric=sqale_index)](https://sonarcloud.io/summary/new_code?id=lucasvieirasilva_aws-codeartifact-poetry)
  [![Lines of Code](https://sonarcloud.io/api/project_badges/measure?project=lucasvieirasilva_aws-codeartifact-poetry&metric=ncloc)](https://sonarcloud.io/summary/new_code?id=lucasvieirasilva_aws-codeartifact-poetry)

  [![Maintainability Rating](https://sonarcloud.io/api/project_badges/measure?project=lucasvieirasilva_aws-codeartifact-poetry&metric=sqale_rating)](https://sonarcloud.io/summary/new_code?id=lucasvieirasilva_aws-codeartifact-poetry)
  [![Reliability Rating](https://sonarcloud.io/api/project_badges/measure?project=lucasvieirasilva_aws-codeartifact-poetry&metric=reliability_rating)](https://sonarcloud.io/summary/new_code?id=lucasvieirasilva_aws-codeartifact-poetry)
  [![Security Rating](https://sonarcloud.io/api/project_badges/measure?project=lucasvieirasilva_aws-codeartifact-poetry&metric=security_rating)](https://sonarcloud.io/summary/new_code?id=lucasvieirasilva_aws-codeartifact-poetry)
  [![Quality Gate Status](https://sonarcloud.io/api/project_badges/measure?project=lucasvieirasilva_aws-codeartifact-poetry&metric=alert_status)](https://sonarcloud.io/summary/new_code?id=lucasvieirasilva_aws-codeartifact-poetry)

  AWS CodeArtifact Poetry CLI is a CLI designed to perform Poetry login with AWS CodeArtifact Private PyPi.



  AWS CodeArtifact is a fully managed artifact repository service that makes it easy for organizations of any size to securely store, publish, and share software packages used in their development process. CodeArtifact supports npm, Maven, and Python packaging formats and allows you to easily integrate with your existing build and deployment workflows.

  However, the AWS CLI does not support Poetry login with AWS CodeArtifact Private PyPi. This CLI was created to solve this problem.



  `pip install aws-codeartifact-poetry`



  ```text
  Usage: aws-codeartifact-poetry [OPTIONS] COMMAND [ARGS]...

    AWS CodeArtifact Poetry CLI.

  Options:
    --loglevel [DEBUG|INFO|WARNING|ERROR|CRITICAL]
                                    Log level.  [default: WARNING]
    --log-file TEXT                 Log file name
    --help                          Show this message and exit.

  Commands:
    login  Login to AWS CodeArtifact
  ```



  ```text
  Usage: aws-codeartifact-poetry login [OPTIONS]

    Login to AWS CodeArtifact

  Options:
    --repository TEXT    Your CodeArtifact repository name  [required]
    --domain TEXT        Your CodeArtifact domain name  [required]
    --domain-owner TEXT  The AWS account ID that owns your CodeArtifact domain
                         [required]
    --profile TEXT       AWS Profile.
    --region TEXT        AWS Region name  [default: us-east-1]
    --help               Show this message and exit.
  ```



  - See our [Contributing Guide](CONTRIBUTING.md)



  - See our [Change Log](CHANGELOG.md)


pkgId: 3bfb4e325efceaea7eaa6fa4985a37d68dc749801010d5eb51b33adae3f8b810
name: python-aws-configure
arch: src
version: 2.1.8
epoch: 0
release: 1
summary: A CLI to configure AWS named profiles in ~/.aws/config and ~/.aws/credentials files
url: https://github.com/qoomon/aws-configure
rpm_license: MIT License
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-configure-2.1.8-1.src.rpm
checksum_type: sha256
description:
  [![PyPI](https://img.shields.io/pypi/v/aws-configure?)](https://pypi.org/project/aws-configure/)

  A CLI to configure AWS named profiles in `~/.aws/config` and `~/.aws/credentials files`


  ```
  list profiles:

        aws-configure list


    set profile options:

        aws-configure set [--profile/-p <profile_name>] [--clean/-c] [<config_options...>]

            --profile/-p <profile_name> : select profile ['default']
            <config_options>            : key=value pairs e.g. 'region=eu-central-1' 'source_profile=default'
            --empty/-e                  : empty all profile options before setting new options
            --empty-config              : empty profile config options before setting
            --empty-credentials         : empty profile credentials options before setting

    get profile options:

        aws-configure get [--profile/-p <profile_name>] [<config_options...>]

            --profile/-p <profile_name> : select profile ['default']
            <config_options>            : option key e.g. 'region' 'source_profile'

    delete profile:

        aws-configure delete [--profile/-p <profile_name>] [--config] [--credentials]

            --profile/-p <profile_name> : select profile ['default']
            --config                    : delete only profile config in '~/.aws/config'
            --credentials               : delete only profile credentials in '~/.aws/credentials'

    print help

        aws-configure help
  ```




  `pip3 install -r requirements.txt`

  `pip3 install -r requirements-dev.txt`


  `python3 setup.py sdist bdist_wheel`


  `pip3 install --force-reinstall --no-deps dist/aws_configure-*-py3-none-any.whl`


  `twine upload dist/*`


pkgId: 2287f420f5de61c35b82e0f39bc40316e2aa034872199a5f097d65ab6d356cfc
name: python-aws-container-launcher
arch: src
version: 4.1.0
epoch: 0
release: 1
url: https://github.com/kankou-aliaksei/aws-container-launcher
rpm_license: UNKNOWN
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-container-launcher-4.1.0-1.src.rpm
checksum_type: sha256
summary:
  AWS Container Launcher makes it easy to programmatically run a Docker container in AWS using the Python package for Batch processing, ML jobs, or fast Web server running.

description:
  * Python 3.7
  * AWS Credentials



  AWS Container Launcher makes it easy to programmatically run a Docker container in AWS using the Python package for Batch processing, ML jobs, or fast Web server running.

  | WARNING: After processing a job, you are in charge of destroying the infrastructure. Do not forget to call the "destroy" method; otherwise, the instance will continue to operate and you will be charged by Amazon. |
  |----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|




  You can specify the instance type explicitly or set the CPU and memory, and the package will automatically select the optimal instance type for you.



  To better understand, familiarize yourself with the available methods and the [start_container](https://github.com/kankou-aliaksei/aws-container-launcher/blob/main/doc/method/START_CONTAINER.MD) method in particular.



  * [Client configuration](https://github.com/kankou-aliaksei/aws-container-launcher/blob/main/doc/client/CONFIGURATION.MD)



  * [start_container](https://github.com/kankou-aliaksei/aws-container-launcher/blob/main/doc/method/START_CONTAINER.MD)
  * [get_container_status](https://github.com/kankou-aliaksei/aws-container-launcher/blob/main/doc/method/GET_CONTAINER_STATUS.MD)
  * [get_container_record](https://github.com/kankou-aliaksei/aws-container-launcher/blob/main/doc/method/GET_CONTAINER_RECORD.MD)
  * [destroy](https://github.com/kankou-aliaksei/aws-container-launcher/blob/main/doc/method/DESTROY.MD)
  * [delete_monitoring_table](https://github.com/kankou-aliaksei/aws-container-launcher/blob/main/doc/method/DELETE_MONITORING_TABLE.MD)



  * [SSD instance store](https://github.com/kankou-aliaksei/aws-container-launcher/blob/main/doc/storage/SSD.MD)
  * [EBS](https://github.com/kankou-aliaksei/aws-container-launcher/blob/main/doc/storage/EBS.MD)
  * [Amazon FSx for Lustre](https://github.com/kankou-aliaksei/aws-container-launcher/blob/main/doc/storage/FSX.MD)
  * [EFS](https://github.com/kankou-aliaksei/aws-container-launcher/blob/main/doc/storage/EFS.MD)



  * [Using spot instances](https://github.com/kankou-aliaksei/aws-container-launcher/blob/main/doc/SPOT_INSTANCE.MD)



  * [Scaling in](https://github.com/kankou-aliaksei/aws-container-launcher/blob/main/doc/scaling/SCALING_IN.MD)


pkgId: a206074d7c93098c74d2794662e19d646ed338d8b004d53f4aadef95d539b2c9
name: python-aws-credential-process
arch: src
version: 0.20.0
epoch: 0
release: 1
summary: AWS Credential Process
url: https://github.com/meeuw/aws-credential-process
rpm_license: UNKNOWN
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-credential-process-0.20.0-1.src.rpm
checksum_type: sha256
description:
  Script to use as `credential_process` for the AWS CLI (including boto3), it
  caches your MFA session in a keyring and can use a Yubi key to authenticate.

  This is useful if you are required to use MFA authenticated sessions or need
  an MFA authenticated session to assume a role.





  You can install aws-credential-process using pip:

  ```bash
  pip install aws_credential_process
  ```

  I recommend to install aws-credential-process in a virtualenv:

  ```bash
  virtualenv ~/venv/aws_credential_process
  ~/venv/aws_credential_process/bin/pip install aws_credential_process
  ```

  After the above commands you should be able to run `~/venv/aws_credential_process/bin/aws-credential-process`




  ```bash
  brew install meeuw/aws-credential-process/aws-credential-process
  ```



  You can use the following arguments to start aws-credential-process:

  ```
  Usage: aws-credential-process [OPTIONS]

    Get output suitable for aws credential process

  Options:
    --version                       Show the version and exit.
    --access-key-id TEXT
    --secret-access-key TEXT
    --mfa-oath-slot TEXT            how the MFA slot is named, check using ykman
                                    oath code
    --mfa-serial-number TEXT        MFA serial number, see IAM console
    --mfa-session-duration INTEGER  duration in seconds, use zero to assume role
                                    without session
    --assume-session-duration INTEGER
                                    duration in seconds
    --assume-role-arn TEXT          IAM Role to be assumed, optional
    --assume-role-policy-arns TEXT  Assume role with policy ARN, can be used
                                    multiple times
    --assume-role-policy TEXT       Assume role with this policy, you can use a
                                    filename if this value starts with @
    --assume-role-source-identity TEXT
                                    The source identity specified by the
                                    principal that is calling the AssumeRole
                                    operation.
    --assume-role-role-session-name TEXT
                                    An identifier for the assumed role session.
    --force-renew-session
    --force-renew-assume-role
    --credentials-section TEXT      Use this section from ~/.aws/credentials
    --pin-entry TEXT                pin-entry helper, should be compatible with
                                    Assuan protocol (GPG)
    --log-file TEXT
    --config-section TEXT           Use this section in config-file
    --config-file TEXT
    --output-format TEXT            Output format, json (default) or shell
    --help                          Show this message and exit.
  ```

  aws-credential-process is meant to be used as `credential_process` in your
  `.aws/config` file. For example:

  ```ini
  [profile yourprofile]
  credential_process = /home/user/venv/aws_credential_process/bin/aws-credential-process --mfa-oath-slot "Amazon Web Services:test@example.com" --mfa-serial-number arn:aws:iam::123456789012:mfa/john.doe --assume-role-arn arn:aws:iam::123456789012:role/YourRole
  ```

  You can also use aws-credential-process to generate exports for your shell which
  is supported by many tools:

  ```bash
  $ $(/home/user/venv/aws_credential_process/bin/aws-credential-process --mfa-oath-slot "Amazon Web Services:test@example.com" --mfa-serial-n  umber arn:aws:iam::123456789012:mfa/john.doe --assume-role-arn arn:aws:iam::123456789012:role/YourRole --output-format shell)
  ```



  aws-credential-process can also use a configuration file, the default location of
  this file is `~/.config/aws-credential-process/config.toml`. This file contains
  defaults so you don't have to supply all of the arguments.

  You can configure a default pin-entry program like:

  ```toml
  pin_entry = /usr/local/bin/pin_entry
  ```

  Or you can define multiple config-sections:

  ```toml
  [123457890123]
  mfa_oath_slot="Amazon Web Services:user@123457890123"
  assume_role_arn="arn:aws:iam::123457890123:role/Other/Role"
  credentials_section="123457890123"
  mfa_serial_number="arn:aws:iam::123457890123:mfa/user"

  [098765432101]
  mfa_oath_slot="Amazon Web Services:user@098765432101"
  credentials_section="098765432101"
  mfa_serial_number="arn:aws:iam::098765432101:mfa/user"
  ```

  If you need to assume roles from a certain AWS account you'll end up with a lot
  of simular entries. To make this simple the configuration can be defined
  hierarchical.

  ```toml
  [[org]]
  mfa_oath_slot="Amazon Web Services:user@123457890123"
  assume_role_arn="arn:aws:iam::{section}:role/Other/Role"
  credentials_section="123457890123"
  mfa_serial_number="arn:aws:iam::123457890123:mfa/user"

  [[org.098765432101]]
  [[org.567890123456]]
  ```

  This would be the same as the following configuration:

  ```toml
  [098765432101]
  mfa_oath_slot="Amazon Web Services:user@123457890123"
  assume_role_arn="arn:aws:iam::098765432101:role/Other/Role"
  credentials_section="123457890123"
  mfa_serial_number="arn:aws:iam::123457890123:mfa/user"

  [567890123456]
  mfa_oath_slot="Amazon Web Services:user@123457890123"
  assume_role_arn="arn:aws:iam::567890123456:role/Other/Role"
  credentials_section="123457890123"
  mfa_serial_number="arn:aws:iam::123457890123:mfa/user"
  ```

  With the above configuration aws-credential-process can be used like this in
  `~/.aws/config`:

  ```ini
  [profile profile1]
  credential_process = /home/user/venv/aws_credential_process/bin/aws-credential-process --config-section=098765432101

  [profile profile2]
  credential_process = /home/user/venv/aws_credential_process/bin/aws-credential-process --config-section=567890123456
  ```



  If you've supplied the secret-access-key once you can omit it with the next call,
  it will be cached in your keyring.

  When you don't supply the access-key-id it will be loaded from `~/.aws/credentials`.
  You can use another section than "default" by using the credentials-section argument.

  If you don't specify `*-session-duration` the default value from AWS will be used
  (3600 seconds). When `--mfa-session-duration` is set to `0` and you use `--assume-role-arn`
  a role will be assumed without using a session. Some API calls can't be made when the role
  is assumed using an MFA session.

  You can also omit the `--assume-role-arn`, then you can use an MFA authenticated session
  using your permanent IAM credentials.


pkgId: 8c5460dbae494bcc63e819b8d47eac6c49f9e864508ca45032d6c7bc1f02f252
name: python-aws-creds
arch: src
version: 2.0.1
epoch: 0
release: 1
summary: Easily switch between AWS Credential profiles.
url: https://github.com/HammoTime/aws-creds
rpm_license: MIT License
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-creds-2.0.1-1.src.rpm
checksum_type: sha256
description:
  Makes it easier to use multiple AWS accounts when you don't have SSO available. You can easily save multiple profiles, and then log into them with an simple set of commands.



  This utility is available in PyPi and can be installed by running:
  ```
  python3 -m pip install aws-creds
  ```



  ```
  MacBook-Pro:aws-creds HammoTime$ aws-creds --help
  Usage: aws-creds [OPTIONS] COMMAND [ARGS]...

    aws-creds makes it easier to use multiple AWS accounts when you don't have
    SSO available.  You can easily save multiple profiles, and then log into
    them with an simple set of commands.

  Options:
    --version  Show the version and exit.
    --help     Show this message and exit.

  Commands:
    add      Adds a new credential profile.
    default  Used to set the defaults for output type and region.
    login    Sets the user's AWS credentials to the selected profile.
    logout   Deletes user's current AWS credentials.
    ls       Lists all of the saved profiles.
    rm       Deletes the selected profile.
    role     Used to login using an assumed role.
    rotate   Automatically rotates your access keys.
    status   Prints out information about the credential that is currently in...
    update   Updates the selected profile with the new values.
  ```



  The following commands are available within the AWS Credential Picker.

  1. ```add```: Add a new credential.
  2. ```rm```: Remove a credential.
  3. ```ls```: List all the saved credentials.
  4. ```login```: Login using a credential.
  5. ```logout```: Remove all of the files used by the aws-cli in ~/.aws.
  6. ```status```: Print details about the current session (account/user).
  7. ```update```: Updates the selected profile with new values.
  8. ```rotate```: Rotates your Access Key if you have a spare slot available.
  9. ```default```: Used to manage default region and output type.
      1. ```get```: Prints out the default region and output type.
      2. ```set```: Sets the default region and output type.
  10. ```role```: Used to manage roles that can be assumed from the cli.
      1. ```add```: Adds a role.
      2. ```assume```: Assumes a saved role.
      3. ```ls```: Lists all roles available to be assumed.
      4. ```rm```: Removes an assumed role permanently from aws-cred config.
      5. ```unassume```: Unassumes a role, switching back to source account.



  The following options are available within the AWS Credential Picker.

  1. ```--help```: Show the help screen.
  2. ```--version```: Print version details.


  The AWS Credential Picker is quite simple in it's design. Instead of storing details in the credentials file - which can prove difficult to use with lots of profiles - we store them in a custom JSON file. When you ```login```, you're actually doing is creating the ```credentials``` and the ```config``` file in ```~/.aws```. When you ```logout```, these files are being deleted.

  The reason this was created is that some AWS Utilities and 3rd Party Tools REALLY do not like it if you have multiple profiles and do not treat environment variables correctly. By always having a single credential set, utilities will ALWAYS work.

  This script also provides an update on how old your Access Key is and advises you when to rotate them.



  - [boto3](https://pypi.org/project/boto3/)
  - [click](https://pypi.org/project/click/)


pkgId: 96697ff049fc8b1d8ff68c9a55945fcbe808c7297f9dfb5ef2f18762aba9768e
name: python-aws-cron-expression-validator
arch: src
version: 1.1.13
epoch: 0
release: 1
url: https://github.com/grumBit/aws_cron_expression_validator.git
rpm_license: MIT License
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-cron-expression-validator-1.1.13-1.src.rpm
checksum_type: sha256
summary:
  ValidatesAWS EventBridge cron expressions, which are similar to, but not compatible with Unix style cron expressions

description:
  ![PyPI](https://img.shields.io/pypi/v/aws_cron_expression_validator)
  ![PyPI - Python Version](https://img.shields.io/pypi/pyversions/aws_cron_expression_validator)
  ![PyPI - Implementation](https://img.shields.io/pypi/implementation/aws_cron_expression_validator)
  ![PyPI - Wheel](https://img.shields.io/pypi/wheel/aws_cron_expression_validator)
  ![PyPI - Status](https://img.shields.io/pypi/status/aws_cron_expression_validator)
  [![GitHub issues](https://img.shields.io/github/issues/grumbit/aws_cron_expression_validator)](https://github.com/grumbit/aws_cron_expression_validator/issues)
  [![GitHub license](https://img.shields.io/github/license/grumbit/aws_cron_expression_validator)](https://github.com/grumbit/aws_cron_expression_validator/blob/master/LICENSE)
  [![GitHub forks](https://img.shields.io/github/forks/grumbit/aws_cron_expression_validator)](https://github.com/grumbit/aws_cron_expression_validator/network)
  [![GitHub stars](https://img.shields.io/github/stars/grumbit/aws_cron_expression_validator)](https://github.com/grumbit/aws_cron_expression_validator/stargazers)



  Validates these [AWS EventBridge cron expressions](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-create-rule-schedule.html#eb-cron-expressions), which are similar to, but not compatible with Unix style cron expressions;

  | Field        | Values          | Wildcards      |
  | :----------- | :-------------- | :------------- |
  | Minute       | 0-59            | , - \* /       |
  | Hour         | 0-23            | , - \* /       |
  | Day-of-month | 1-31            | , - \* ? / L W |
  | Month        | 1-12 or JAN-DEC | , - \* /       |
  | Day-of-week  | 1-7 or SUN-SAT  | , - \* ? L #   |
  | Year         | 1970-2199       | , - \* /       |

  _NB: It appears AWS is supporting the Quartz Job Scheduler cron expressions. More details than AWS provides is available in the [Cron Trigger Tutorial](http://www.quartz-scheduler.org/documentation/quartz-2.3.0/tutorials/crontrigger.html)._

  This was inspired by Niloy Chakraborty's [AWSCronValidator.py](https://gist.github.com/ultrasonex/e1fdb8354408a56df91aa4902d17aa6a) project.



  To install the library run;

  ```bash
  pip install aws-cron-expression-validator
  ```



  ```python
  from aws_cron_expression_validator.validator import AWSCronExpressionValidator, AWSCronExpressionMinuteError

  my_expression = "0 180 ? * MON-FRI *"
  try:
      AWSCronExpressionValidator.validate(my_expression)
  except AWSCronExpressionMinuteError:
      print(f"Oh no! My expression has an invalid minute field: {e}")
  except ValueError as e:
      print(f"Oh no! My expression was invalid: {e}")
  ```


pkgId: 176cf65f509d9e48034d3fe8a35ede7b782af073330199a56cca0bba94bfbe69
name: python-aws-data-landing-zone
arch: src
version: 0.0.40
epoch: 0
release: 1
summary: AWS CDK Data Landing Zone construct
url: https://github.com/DataChefHQ/aws-data-landing-zone.git
rpm_license: Apache-2.0
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-data-landing-zone-0.0.40-1.src.rpm
checksum_type: sha256
description:
  <!-- TOC -->

  * [Getting Started](#getting-started)

    * [Typescript](#typescript)
    * [Python](#python-example)
  * [Key Features](#key-features)
  * [Intended Audience](#intended-audience)
  * [Core Principles](#core-principles)
  * [Integrated AWS Services](#integrated-aws-services)
  * [How it works](#how-it-works)
  * [Sponsors](#sponsors)
  * [Contributing](#contributing)
  * [Docs](#docs)
  * [Roadmap](#roadmap)

  <!-- TOC -->

  The **Data Landing Zone (DLZ)** is a CDK construct designed to accelerate AI and data-related projects. It provides an
  opinionated Landing Zone, laying the foundation for a multi-account AWS strategy, so you can focus on delivering data
  and AI solutions.

  The DLZ can be deployed in existing AWS Organizations or used in greenfield projects. It supports setups ranging
  from small organizations with a few accounts to large enterprises with hundreds of accounts.

  See the Documentation Website: https://datalandingzone.com/ for more information.

  The CDK construct is available in both TypeScript and Python. Example GitHub repositories showing usage:

  * [TypeScript Example GitHub Repo](https://github.com/DataChefHQ/aws-data-landing-zone-example-typescript)
  * [Python Example GitHub Repo](https://github.com/DataChefHQ/aws-data-landing-zone-example-python)





  Install the [aws-data-landing-zone](https://www.npmjs.com/package/aws-data-landing-zone) CDK construct from NPM:

  ```bash
  npm install aws-data-landing-zone
  ```

  Use the construct as a stack in your CDK application. Replace the `organizationId`, `ouId`, `ous`, `accountId`, and
  `regions` with your own values as per AWS Control Tower & AWS Organizations.

  The example below shows a simple DLZ setup with two accounts, one for development and one for production, creating
  two non-overlapping VPCs in two regions in each account.

  ```python
  import {App} from 'aws-cdk-lib';
  import { DataLandingZone } from '@DataChefHQ/data-landing-zone';

  const app = new App();
  const dlz = new DataLandingZone(app, {
    ...
    regions: {
      global: Region.EU_WEST_1,
      regional: [Region.US_EAST_1],
    },
    organization: {
      organizationId: 'o-0f5h921gk9',
      root: { accounts: { management: { accountId: '123456789012', }, }, },
      ous: {
        workloads: {
          ouId: 'ou-h2l0-gjr36ikn',
          accounts: [{
              name: 'development',
              accountId: '123456789012',
              type: DlzAccountType.DEVELOP,
              vpcs: [
                Defaults.vpcClassB3Private3Public(0, Region.US_EAST_1),
                Defaults.vpcClassB3Private3Public(1, Region.EU_WEST_1),
              ],
            },{
              name: 'production',
              accountId: '123456789012',
              type: DlzAccountType.PRODUCTION,
              vpcs: [
                Defaults.vpcClassB3Private3Public(2, Region.US_EAST_1),
                Defaults.vpcClassB3Private3Public(3, Region.EU_WEST_1),
              ],
            },

            ...AS MANY ACCOUNTS AS DESIRED...

            ]
        },
     },
     ...
   }
  });
  ```

  Continue reading [Getting Started](https://datalandingzone.com/getting-started/) on the DLZ documentation site.



  Install the [aws-data-landing-zone](https://pypi.org/project/aws-data-landing-zone/#description) CDK construct from PyPi:

  ```bash
  pip install aws-data-landing-zone
  ```

  Use the construct as a stack in your CDK application. Replace the `organizationId`, `ouId`, `ous`, `accountId`, and
  `regions` with your own values as per AWS Control Tower & AWS Organizations.

  The example below shows a simple DLZ setup with two accounts, one for development and one for production, creating
  two non-overlapping VPCs in two regions in each account.

  ```python

  import aws_cdk as cdk
  import recipes_dlz as dlz

  app = cdk.App()
  dlz.DataLandingZone(app,
      local_profile="ct-sandbox-exported",
      regions=dlz.DlzRegions(
          global_=dlz.Region.EU_WEST_1,
          regional=[dlz.Region.US_EAST_1],
      ),
      organization=dlz.DLzOrganization(
          organization_id='o-0f5h921gk9',
          root=dlz.RootOptions(
              accounts=dlz.OrgRootAccounts(
                  management=dlz.DLzManagementAccount(account_id='123456789012'),
              ),
          ),
          ous=dlz.OrgOus(
              workloads=dlz.OrgOuWorkloads(
                  ou_id='ou-h2l0-gjr36ikn',
                  accounts=[
                      dlz.DLzAccount(
                          name='development',
                          account_id='123456789012',
                          type=dlz.DlzAccountType.DEVELOP,
                          vpcs=[
                              dlz.Defaults.vpc_class_b3_private3_public(0, dlz.Region.US_EAST_1),
                              dlz.Defaults.vpc_class_b3_private3_public(1, dlz.Region.EU_WEST_1),
                          ]
                      ),
                      dlz.DLzAccount(
                          name='production',
                          account_id='123456789012',
                          type=dlz.DlzAccountType.PRODUCTION,
                          vpcs=[
                              dlz.Defaults.vpc_class_b3_private3_public(2, dlz.Region.US_EAST_1),
                              dlz.Defaults.vpc_class_b3_private3_public(3, dlz.Region.EU_WEST_1),
                          ]
                      ),
                  ],
              ),
          )
      ),
  )
  app.synth()
  ```

  Continue reading [Getting Started](https://datalandingzone.com/getting-started/) on the DLZ documentation site.



  Notable features of the DLZ include:

  * A CDK construct that can be used in TS and Python
  * Opinionated but configurable and extendable. Each stack and nested component can be extended if needed.
  * Leverages AWS Control Tower. Works with existing or new AWS Control Tower setups.
  * Suitable for greenfield projects or integration with existing AWS resources.
  * Deployable using any build systems like GitHub, GitLab, Jenkins, or locally.
  * Generates compliance reports, reporting the Control Tower Standards, SecurityHub controls, Config Rules and
    Service Control Policies enabled in each account.
  * Implements an internal wave- and stage-based deployment strategy for dependency management.
  * Includes helper scripts and Standard Operating Procedures (SOPs) for routine tasks.
  * Accompanied by comprehensive documentation.



  The DLZ handles the responsibilities and routine tasks typically managed by a Cloud Center of Excellence (CCoE) team.
  It's easy enough for Data Engineers to use on their own, but flexible enough to be customized and fine-tuned by
  experienced Cloud Engineers.

  It's important to establish the following responsibilities to understand what is in and out of scope for the DLZ:

  * **In scope** - Any CCoE responsibilities and tasks, such as account management, security, networking, compliance, etc.
  * **Out of scope** - Application development, data engineering, and data science tasks.



  The DLZ adheres to the following principles:

  1. Opinionated but configurable defaults to suit diverse needs.
  2. High levels of automation with manual SOPs where needed.
  3. Simplicity and ease of understanding over complexity
  4. Focused scope, limited to Landing Zone responsibilities.



  * **AWS Organizations:** Seamless multi-account management.
  * **AWS Budgets:** Track spending by tags with notifications via Slack, Teams, or email.
  * **Service Control Policies (SCPs):** Manage service deny lists.
  * **Tag Policies:** Enforce resource tagging for spend tracking and ownership.
  * **Control Tower Controls:** Opinionated defaults for preventive, detective, and proactive standards.
  * **AWS Security Hub** and **AWS Config:** Additional standards not covered by Control Tower. Notifications are
    delivered via Slack, Teams, or email
  * **Network Management:**

    * Non-overlapping **VPCs** across accounts.
    * **NAT Gateways** or instances for outbound private access.
    * **VPC Peering** for cross-account/region communication.
    * **Bastion Hosts** with **AWS SSM** for secure private resource access.
    * Simplified routing configurations.
  * **IAM Identity Center (SSO):**

    * User management with **AWS Identity Store** or external IDPs (e.g., Google, Active Directory).
    * Manage **Permission Sets**
    * Manage **Access Groups** to assign Users to Accounts with a given Permission Set
  * **Permission Boundaries:** Prevent privilege escalation for all IAM roles and users.
  * Configure **Lake Formation** for Data Lake management, including:

    * General settings, like admins, version and setting hybrid iam mode
    * Create **Tags** and specify their permissions for use within the same account and when sharing to other accounts.
    * Optionally, set **Tag Permissions** on Tags. This is usually out of scope for DLZ, but can be configured.



  The DLZ defines all accounts and resources in a single CDK construct that can be used in Typescript or Python CDK
  project.

  The DLZ deploys resources into specified AWS accounts. These accounts must be created manually (SOP provided) in the
  workloads OU, and their Account IDs must be provided in the DLZ configuration. Each account is designated
  as either `development` or `production` to enable controlled, staged deployments, including the option for manual
  approvals in production environments.

  The construct processes the provided configuration to create logical deployment layers for resources. Each layer
  consists of a Global Wave and optionally one or more Regional Waves. This structure ensures that all `global` stacks
  for the accounts are deployed before the `regional` stacks. Resources in the `global` stack are region-independent, such
  as IAM roles, whereas resources like VPCs can be deployed in both `global` and `regional` stacks if configured as such.

  Continue reading the [Introduction](https://datalandingzone.com/introduction/) on the Data Landing Zone documentation site.



  Proudly sponsored and created by [DataChef](https://datachef.co.za/)



  See [CONTRIBUTING.md](CONTRIBUTING.md) for more info



  Can be found at https://datalandingzone.com/



  Can be found in the [here](https://github.com/orgs/DataChefHQ/projects/4)


pkgId: f9f4ddeda9da9caa961991ef9080f515049c4ad2154bca7c974027d60e27e71b
name: python-aws-dynamodb-parallel-scan
arch: src
version: 1.1.0
epoch: 0
release: 1
summary: Amazon DynamoDB Parallel Scan Paginator for boto3.
url: https://pypi.org/project/aws-dynamodb-parallel-scan/
rpm_license: None
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-dynamodb-parallel-scan-1.1.0-1.src.rpm
checksum_type: sha256
description:
  Amazon DynamoDB parallel scan paginator for boto3.



  Install from PyPI with pip

  ```
  pip install aws-dynamodb-parallel-scan
  ```

  or with the package manager of choice.



  The library is a drop-in replacement for [boto3 DynamoDB Scan Paginator](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/dynamodb.html#DynamoDB.Paginator.Scan). Example:

  ```python
  import aws_dynamodb_parallel_scan
  import boto3


  client = boto3.resource("dynamodb").meta.client


  paginator = aws_dynamodb_parallel_scan.get_paginator(client)


  for page in paginator.paginate(TableName="mytable", TotalSegments=5):
      items = page.get("Items", [])
  ```

  Notes:

  * `paginate()` accepts the same arguments as boto3 `DynamoDB.Client.scan()` method. Arguments
    are passed to `DynamoDB.Client.scan()` as-is.

  * `paginate()` uses the value of `TotalSegments` argument as parallelism level. Each segment
    is scanned in parallel in a separate thread.

  * `paginate()` yields DynamoDB Scan API responses in the same format as boto3
    `DynamoDB.Client.scan()` method.

  See boto3 [DynamoDB.Client.scan() documentation](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/dynamodb.html#DynamoDB.Client.scan)
  for details on supported arguments and the response format.



  This package also provides a CLI tool (`aws-dynamodb-parallel-scan`) to scan a DynamoDB table
  with parallel scan. The tool supports all non-deprecated arguments of DynamoDB Scan API. Execute
  `aws-dynamodb-parallel-scan -h` for details

  Here's some examples:

  ```bash

  $ aws-dynamodb-parallel-scan --table-name mytable
  {"Items": [...], "Count": 10256, "ScannedCount": 10256, "ResponseMetadata": {}}
  {"Items": [...], "Count": 12, "ScannedCount": 12, "ResponseMetadata": {}}


  $ aws-dynamodb-parallel-scan --table-name mytable --total-segments 5
  {"Items": [...], "Count":32, "ScannedCount":32, "ResponseMetadata": {}}
  {"Items": [...], "Count":47, "ScannedCount":47, "ResponseMetadata": {}}
  {"Items": [...], "Count":52, "ScannedCount":52, "ResponseMetadata": {}}
  {"Items": [...], "Count":34, "ScannedCount":34, "ResponseMetadata": {}}
  {"Items": [...], "Count":40, "ScannedCount":40, "ResponseMetadata": {}}


  $ aws-dynamodb-parallel-scan --table-name mytable --total-segments 5 \
      --output-items
  {"pk": {"S": "item1"}, "quantity": {"N": "99"}}
  {"pk": {"S": "item24"}, "quantity": {"N": "25"}}
  ...


  $ aws-dynamodb-parallel-scan --table-name mytable --total-segments 5 \
      --output-items --use-document-client
  {"pk": "item1", "quantity": 99}
  {"pk": "item24", "quantity": 25}
  ...


  $ aws-dynamodb-parallel-scan --table-name mytable --total-segments 5 \
      --filter-expression "quantity < :value" \
      --expression-attribute-values '{":value": {"N": "5"}}' \
      --output-items
  {"pk": {"S": "item142"}, "quantity": {"N": "4"}}
  {"pk": {"S": "item874"}, "quantity": {"N": "1"}}


  $ aws-dynamodb-parallel-scan --table-name mytable --total-segments 5 \
      --filter-expression "quantity < :value" \
      --expression-attribute-values '{":value": 5}' \
      --use-document-client --output-items
  {"pk": "item142", "quantity": 4}
  {"pk": "item874", "quantity": 1}
  ```



  Requires Python 3 and uv. Useful commands:

  ```bash

  make test


  make -k lint


  make format
  ```



  MIT



  * Alex Chan, [Getting every item from a DynamoDB table with Python](https://alexwlchan.net/2020/05/getting-every-item-from-a-dynamodb-table-with-python/)


pkgId: 90ab5fede0a59d8747a28844d6aea3256b69e5a1d357ee20c07b894533be7e9f
name: python-aws-dynamodb-parser
arch: src
version: 0.1.3
epoch: 0
release: 1
summary: AWS DynamoDB utility for parsing DynamoDB responses
url: https://github.com/gridsmartercities/aws-dynamodb-parser
rpm_license: MIT
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-dynamodb-parser-0.1.3-1.src.rpm
checksum_type: sha256
description:
  [<img align="right" alt="Grid Smarter Cities" src="https://s3.eu-west-2.amazonaws.com/open-source-resources/grid_smarter_cities_small.png">](https://www.gridsmartercities.com/)

  ![Build Status](https://codebuild.eu-west-2.amazonaws.com/badges?uuid=eyJlbmNyeXB0ZWREYXRhIjoiZGdTRFhHdng1Mks0THRaT2VkR3JYaWpOWGlwNjYvVGVYWUNoZGp6VW9MZDRMZ1I0WDFVNFJ0cHBORkJJVSswMWQ1VkxISGNFR1dWTElrWThDTVBldjUwPSIsIml2UGFyYW1ldGVyU3BlYyI6IlFMS1V1K0F5a1BHRTZlN0IiLCJtYXRlcmlhbFNldFNlcmlhbCI6MX0%3D&branch=master)
  [![License: MIT](https://img.shields.io/badge/License-MIT-brightgreen.svg)](https://opensource.org/licenses/MIT)
  [![PyPI](https://img.shields.io/pypi/v/aws-dynamodb-parser.svg?color=brightgreen)](https://pypi.org/project/aws-dynamodb-parser/)



  AWS DynamoDB utility for parsing DynamoDB responses


  ```
  pip install aws-dynamodb-parser
  ```



  `parse` is the main method exposed for parsing DynamoDB responses when using `boto3`.

  The `parse` function can handle [all of the data types AWS DynamoDB supports](https://boto3.amazonaws.com/v1/documentation/api/latest/_modules/boto3/dynamodb/types.html) as of October 2020.


  Assuming we have a table `TABLE_NAME` containing the following entries, with `id` set as the partition key and `timestamp` as the sort key.

  All three fields included are strings.

  |id                                  |timestamp                 |name             |
  |------------------------------------|--------------------------|-----------------|
  |a77b5fc0-75cb-408c-bebf-863873506cce|2020-10-01 13:13:47.388492|First test entry |
  |a77b5fc0-75cb-408c-bebf-863873506cce|2020-10-01 13:15:25.376589|Second test entry|
  |fa853ff0-706e-45db-b6ae-aa6a8a1f7856|2020-10-01 13:16:47.720778|Third test entry |


  Parsing the result from a `get_item` request:

  ```py
  import boto3
  from aws_dynamodb_parser import parse

  dynamodb_client = boto3.client("dynamodb")
  response = dynamodb_client.get_item(
      TableName="TABLE_NAME",
      Key={
          "id": {"S": "a77b5fc0-75cb-408c-bebf-863873506cce"},
          "timestamp": {"S": "2020-10-01 13:13:47.388492"}
      }
  )

  item = response.get("Item", {})
  print(item)


  entry = parse(item)
  print(entry)

  ```

  Parsing the result from a `query` request:

  ```py
  import boto3
  from aws_dynamodb_parser import parse

  dynamodb_client = boto3.client("dynamodb")
  response = dynamodb_client.query(
      TableName="TABLE_NAME",
      KeyConditionExpression="#id = :id",
      ExpressionAttributeNames={
          "#id": "id"
      },
      ExpressionAttributeValues={
          ":id": {"S": "a77b5fc0-75cb-408c-bebf-863873506cce"}
      }
  )

  items = response.get("Items", [])
  print(items)


  entries = parse(items)
  print(entries)

  ```


  Users can get the docstring help by running:
  ```py
  from aws_dynamodb_parser import parse
  help(parse)
  ```


  - [Github](https://github.com/gridsmartercities/aws-dynamodb-parser)
  - [PyPI](https://pypi.org/project/aws-dynamodb-parser/)
  - [Test PyPI](https://test.pypi.org/project/aws-dynamodb-parser/)


pkgId: 95c726af43fb8b4b1e230f0bc03ef9dd8fb51f040e63aa7e883921f1a77441c5
name: python-aws-embedded-metrics
arch: src
version: 3.2.0
epoch: 0
release: 1
summary: AWS Embedded Metrics Package
url: https://github.com/awslabs/aws-embedded-metrics-python
rpm_license: Apache Software License
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-embedded-metrics-3.2.0-1.src.rpm
checksum_type: sha256
description:
  ![](https://codebuild.us-west-2.amazonaws.com/badges?uuid=eyJlbmNyeXB0ZWREYXRhIjoidjNkYXpXTzMxdUY2dEdab2RaZTgvTXhUSGh2bjNmUlhmUEorejM0UytyOWNqeFptcUpBT2wzNkJ1MkExQXI3UFdNaGQzNlVmSzBPWkRhdmhkb2lqL05NPSIsIml2UGFyYW1ldGVyU3BlYyI6IkhKZS9rd2UwYzVud1VucVgiLCJtYXRlcmlhbFNldFNlcmlhbCI6MX0%3D&branch=master)
  [![](https://img.shields.io/pypi/v/aws-embedded-metrics)](https://pypi.org/project/aws-embedded-metrics/)

  Generate CloudWatch Metrics embedded within structured log events. The embedded metrics will be extracted so you can visualize and alarm on them for real-time incident detection. This allows you to monitor aggregated values while preserving the detailed event context that generated them.

  - [Use Cases](#use-cases)
  - [Installation](#installation)
  - [Usage](#usage)
  - [API](#api)
  - [Examples](#examples)
  - [Development](#development)



  - **Generate custom metrics across compute environments**

    - Easily generate custom metrics from Lambda functions without requiring custom batching code, making blocking network requests or relying on 3rd party software.
    - Other compute environments (EC2, On-prem, ECS, EKS, and other container environments) are supported by installing the [CloudWatch Agent](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Embedded_Metric_Format_Generation_CloudWatch_Agent.html).
    	- Examples can be found in [examples/README.md](examples/README.md)

  - **Linking metrics to high cardinality context**

    Using the Embedded Metric Format, you will be able to visualize and alarm on custom metrics, but also retain the original, detailed and high-cardinality context which is queryable using [CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html). For example, the library automatically injects environment metadata such as Lambda Function version, EC2 instance and image ids into the structured log event data.



  ```
  pip3 install aws-embedded-metrics
  ```



  To get a metric logger, you can decorate your function with a `metric_scope`:

  ```py
  from aws_embedded_metrics import metric_scope
  from aws_embedded_metrics.storage_resolution import StorageResolution

  @metric_scope
  def my_handler(metrics):
      metrics.put_dimensions({"Foo": "Bar"})
      metrics.put_metric("ProcessingLatency", 100, "Milliseconds", StorageResolution.STANDARD)
      metrics.put_metric("Memory.HeapUsed", 1600424.0, "Bytes", StorageResolution.HIGH)
      metrics.set_property("AccountId", "123456789012")
      metrics.set_property("RequestId", "422b1569-16f6-4a03")
      metrics.set_property("DeviceId", "61270781-c6ac-46f1")

      return {"message": "Hello!"}
  ```





  The `MetricsLogger` is the interface you will use to publish embedded metrics.

  - **put_metric**(key: str, value: float, unit: str = "None", storage_resolution: int = 60) -> MetricsLogger

  Adds a new metric to the current logger context. Multiple metrics using the same key will be appended to an array of values. Multiple metrics cannot have same key and different storage resolution. The Embedded Metric Format supports a maximum of 100 values per key. If more metric values are added than are supported by the format, the logger will be flushed to allow for new metric values to be captured.

  Requirements:

  - Name Length 1-255 characters
  - Name must be ASCII characters only
  - Values must be in the range of 8.515920e-109 to 1.174271e+108. In addition, special values (for example, NaN, +Infinity, -Infinity) are not supported.
  - Metrics must meet CloudWatch Metrics requirements, otherwise a `InvalidMetricError` will be thrown. See [MetricDatum](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_MetricDatum.html) for valid values.

  - ##### Storage Resolution
  An OPTIONAL value representing the storage resolution for the corresponding metric. Setting this to `High` specifies this metric as a high-resolution metric, so that CloudWatch stores the metric with sub-minute resolution down to one second. Setting this to `Standard` specifies this metric as a standard-resolution metric, which CloudWatch stores at 1-minute resolution. If a value is not provided, then a default value of `Standard` is assumed. See [Cloud Watch High-Resolution metrics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html#high-resolution-metrics)

  Examples:

  ```py

  put_metric("Latency", 200, "Milliseconds")
  put_metric("Latency", 201, "Milliseconds", StorageResolution.STANDARD)


  put_metric("Memory.HeapUsed", 1600424.0, "Bytes", StorageResolution.HIGH)
  ```

  - **set_property**(key: str, value: Any) -> MetricsLogger

  Adds or updates the value for a given property on this context. This value is not submitted to CloudWatch Metrics but is searchable by CloudWatch Logs Insights. This is useful for contextual and potentially high-cardinality data that is not appropriate for CloudWatch Metrics dimensions.

  Requirements:

  - Length 1-255 characters

  Examples:

  ```py
  set_property("RequestId", "422b1569-16f6-4a03-b8f0-fe3fd9b100f8")
  set_property("InstanceId", "i-1234567890")
  set_property("Device", {
    "Id": "61270781-c6ac-46f1-baf7-22c808af8162",
    "Name": "Transducer",
    "Model": "PT-1234"
  })
  ```

  - **put_dimensions**(dimensions: Dict[str, str]) -> MetricsLogger

  Adds a new set of dimensions that will be associated to all metric values.

  **WARNING**: Every distinct value will result in a new CloudWatch Metric.
  If the cardinality of a particular value is expected to be high, you should consider
  using `setProperty` instead.

  Requirements:

  - Length 1-255 characters
  - ASCII characters only
  - Dimensions must meet CloudWatch Dimensions requirements, otherwise a `InvalidDimensionError` or `DimensionSetExceededError` will be thrown. See [Dimensions](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_Dimension.html) for valid values.

  Examples:

  ```py
  put_dimensions({ "Operation": "Aggregator" })
  put_dimensions({ "Operation": "Aggregator", "DeviceType": "Actuator" })
  ```

  - **set_dimensions**(\*dimensions: Dict[str, str], use_default: bool = False) -> MetricsLogger

  Explicitly override all dimensions. By default, this will disable the default dimensions, but can be configured using the *keyword-only* parameter `use_default`.

  **WARNING**: Every distinct value will result in a new CloudWatch Metric.
  If the cardinality of a particular value is expected to be high, you should consider
  using `setProperty` instead.

  Requirements:

  - Length 1-255 characters
  - ASCII characters only
  - Dimensions must meet CloudWatch Dimensions requirements, otherwise a `InvalidDimensionError` or `DimensionSetExceededError` will be thrown. See [Dimensions](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_Dimension.html) for valid values.

  Examples:

  ```py
  set_dimensions(
    { "Operation": "Aggregator" },
    { "Operation": "Aggregator", "DeviceType": "Actuator" }
  )
  ```

  ```py
  set_dimensions(
    { "Operation": "Aggregator" },
    use_default=True  # default dimensions would be enabled
  )
  ```

  - **reset_dimensions**(use_default: bool) -> MetricsLogger

  Explicitly clear all custom dimensions. The behavior of whether default dimensions should be used can be configured with the `use_default` parameter.

  Examples:

  ```py
  reset_dimensions(False)  # this will clear all custom dimensions as well as disable default dimensions
  ```

  - **set_namespace**(value: str) -> MetricsLogger

  Sets the CloudWatch [namespace](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Namespace) that extracted metrics should be published to. If not set, a default value of aws-embedded-metrics will be used.

  Requirements:

  - Name Length 1-255 characters
  - Name must be ASCII characters only
  - Namespace must meet CloudWatch Namespace requirements, otherwise a `InvalidNamespaceError` will be thrown. See [Namespaces](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Namespace) for valid values.

  Examples:

  ```py
  set_namespace("MyApplication")
  ```

  - **set_timestamp**(timestamp: datetime) -> MetricsLogger

  Sets the timestamp of the metrics. If not set, current time of the client will be used.

  Timestamp must meet CloudWatch requirements, otherwise a InvalidTimestampError will be thrown. See [Timestamps](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#about_timestamp) for valid values.

  Examples:

  ```py
      set_timestamp(datetime.datetime.now())
  ```



  - **flush**()

  Flushes the current MetricsContext to the configured sink and resets all properties and metric values. The namespace and default dimensions will be preserved across flushes.
  Custom dimensions are **not** preserved by default, but this behavior can be changed by setting `logger.flush_preserve_dimensions = True`, so that custom dimensions would be preserved after each flushing thereafter.

  Example:

  ```py
  logger.flush()  # only default dimensions will be preserved after each flush()
  ```

  ```py
  logger.flush_preserve_dimensions = True
  logger.flush()  # custom dimensions and default dimensions will be preserved after each flush()
  ```

  ```py
  logger.reset_dimensions(False)
  logger.flush()  # default dimensions are disabled; no dimensions will be preserved after each flush()
  ```



  All configuration values can be set using environment variables with the prefix (`AWS_EMF_`). Configuration should be performed as close to application start up as possible.

  **ServiceName**: Overrides the name of the service. For services where the name cannot be inferred (e.g. Java process running on EC2), a default value of Unknown will be used if not explicitly set.

  Requirements:

  - Name Length 1-255 characters
  - Name must be ASCII characters only

  Example:

  ```py

  from aws_embedded_metrics.config import get_config
  Config = get_config()
  Config.service_name = "MyApp"


  AWS_EMF_SERVICE_NAME = MyApp
  ```

  **ServiceType**: Overrides the type of the service. For services where the type cannot be inferred (e.g. Java process running on EC2), a default value of Unknown will be used if not explicitly set.

  Requirements:

  - Name Length 1-255 characters
  - Name must be ASCII characters only

  Example:

  ```py

  from aws_embedded_metrics.config import get_config
  Config = get_config()
  Config.service_type = "NodeJSWebApp"


  AWS_EMF_SERVICE_TYPE = NodeJSWebApp
  ```

  **LogGroupName**: For agent-based platforms, you may optionally configure the destination log group that metrics should be delivered to. This value will be passed from the library to the agent in the Embedded Metric payload. If a LogGroup is not provided, the default value will be derived from the service name: <service-name>-metrics

  Requirements:

  - Name Length 1-512 characters
  - Log group names consist of the following characters: a-z, A-Z, 0-9, '\_' (underscore), '-' (hyphen), '/' (forward slash), and '.' (period). Pattern: [\.\-_/#A-Za-z0-9]+

  Example:

  ```py

  from aws_embedded_metrics.config import get_config
  Config = get_config()
  Config.log_group_name = "LogGroupName"


  AWS_EMF_LOG_GROUP_NAME = LogGroupName
  ```

  **LogStreamName**: For agent-based platforms, you may optionally configure the destination log stream that metrics should be delivered to. This value will be passed from the library to the agent in the Embedded Metric payload. If a LogGroup is not provided, the default value will be derived by the agent (this will likely be the hostname).

  Requirements:

  - Name Length 1-512 characters
  - The ':' (colon) and '\*' (asterisk) characters are not allowed. Pattern: [^:]\*

  Example:

  ```py

  from aws_embedded_metrics.config import get_config
  Config = get_config()
  Config.log_stream_name = "LogStreamName"


  AWS_EMF_LOG_STREAM_NAME = LogStreamName
  ```

  **NameSpace**: Overrides the CloudWatch [namespace](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Namespace). If not set, a default value of aws-embedded-metrics will be used.

  Requirements:

  - Name Length 1-512 characters
  - Name must be ASCII characters only

  Example:

  ```py

  from aws_embedded_metrics.config import get_config
  Config = get_config()
  Config.namespace = "MyApplication"


  AWS_EMF_NAMESPACE = MyApplication
  ```

  **DISABLE_METRIC_EXTRACTION**: Disables extraction of metrics by CloudWatch, by omitting EMF
  metadata from serialized log records.

  Example:

  ```py

  from aws_embedded_metrics.config import get_config
  Config = get_config()
  Config.disable_metric_extraction = True


  AWS_EMF_DISABLE_METRIC_EXTRACTION = true
  ```



  Check out the [examples](https://github.com/awslabs/aws-embedded-metrics-python/tree/master/examples) directory to get started.



  1. Install Test Dependencies

  ```
  pip install tox
  ```

  2. Run tests

  ```
  tox
  ```

  3. Integration tests. These tests require Docker to run the CloudWatch Agent and valid AWS credentials. Tests can be run by:

  ```sh
  export AWS_ACCESS_KEY_ID=
  export AWS_SECRET_ACCESS_KEY=
  export AWS_REGION=us-west-2
  ./bin/run-integ-tests.sh
  ```



  This project is licensed under the Apache-2.0 License.


pkgId: cfbe81a36ea71470578b8b4a939c3e25aeb5677d3cb73b36d056872436fb5685
name: python-aws-encryption-sdk-cli
arch: src
version: 4.2.0
epoch: 0
release: 1
description:
  * Python 3.8+
  * aws-encryption-sdk >= 3.1.0

url: http://aws-encryption-sdk-cli.readthedocs.io/en/latest/
rpm_license: Apache License 2.0
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-encryption-sdk-cli-4.2.0-1.src.rpm
checksum_type: sha256
summary:
  This command line tool can be used to encrypt and decrypt files and directories using the AWS Encryption SDK.


pkgId: d721ace9e825fef4f3b2968428b8853c6781579ccea5ce636a352a20fcb5c3f0
name: python-aws-error-utils
arch: src
version: 2.7.0
epoch: 0
release: 1
summary: Error-handling functions for boto3/botocore
url: https://github.com/benkehoe/aws-error-utils
rpm_license: Apache-2.0
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-error-utils-2.7.0-1.src.rpm
checksum_type: sha256
description:
  **Making botocore.exceptions.ClientError easier to deal with**

  All AWS service exceptions are raised by `boto3` as a `botocore.exceptions.ClientError`, with the contents of the exception indicating what kind of exception happened.
  This is not very pythonic, and the contents themselves are rather opaque, most being held in dicts rather than as properties.
  The functions in this package help dealing with that, to make your code less verbose and require less memorization of `ClientError` contents.



  [The package is on PyPI](https://pypi.org/project/aws-error-utils/) for pip-installing, but you can also just copy the [`aws_error_utils.py` file](https://raw.githubusercontent.com/benkehoe/aws-error-utils/stable/aws_error_utils/aws_error_utils.py) into your project (note that the standalone file requires Python 3.7 or greater).


  If you've got code like this:

  ```python
  import boto3, botocore.exceptions

  s3 = boto3.client('s3')
  try:
      s3.get_object(Bucket='my-bucket', Key='example')
  except botocore.exceptions.ClientError as error:
      if error.response['Error']['Code'] == 'NoSuchBucket':
          print(error.response['Error']['Message'])
          
      else:
          raise
  ```

  you can replace it with:

  ```python
  import boto3
  from aws_error_utils import errors

  s3 = boto3.client('s3')
  try:
      s3.get_object(Bucket='my-bucket', Key='example')
  except errors.NoSuchBucket as error:


      print(error.message)
      
  ```

  If you have trouble remembering where all the contents in `ClientError` are, like these:

  ```python
  client_error.response['Error']['Code']
  client_error.response['Error']['Message']
  client_error.response['ResponseMetadata']['HTTPStatusCode']
  client_error.operation_name
  ```

  you can replace it with:

  ```python
  import boto3
  from aws_error_utils import get_aws_error_info

  err_info = get_aws_error_info(client_error)

  err_info.code
  err_info.message
  err_info.http_status_code
  err_info.operation_name
  ```

  If you're using `errors` or `catch_aws_error()`, you can skip the `get_aws_error_info()` step, because the fields are set directly on the `ClientError` object:

  ```python
  import boto3
  from aws_error_utils import errors

  s3 = boto3.client('s3')
  try:
      s3.get_object(Bucket='my-bucket', Key='example')
  except errors.NoSuchBucket as error:
      error.code
      error.message
      error.http_status_code
      error.operation_name
  ```

  Additionally, when you *do* need to use `ClientError`, it's imported by `aws_error_utils` so you can just use `aws_error_utils.ClientError` rather than `botocore.exceptions.ClientError` (the same is true for `BotoCoreError`, the base class of all non-`ClientError` exceptions).


  It's easiest to use the `errors` class if you don't have complex conditions to match.
  Using the error code as a field name in an `except` block will match that error code.
  Additionally, when you use this style, it sets the fields from `AWSErrorInfo` (see below) directly on the `ClientError` object.
  For example:

  ```python
  import boto3
  from aws_error_utils import errors

  s3 = boto3.client('s3')
  try:
      s3.get_object(Bucket='my-bucket', Key='example')
  except errors.NoSuchBucket as error:
      print(error.message)

      
  ```

  You can include multiple error codes in an `except` statement, though this is slower than combining them with a single `catch_aws_error()` call.

  ```python
  import boto3
  from aws_error_utils import errors

  s3 = boto3.client('s3')
  try:
      s3.get_object(Bucket='my-bucket', Key='example')
  except (errors.NoSuchBucket, errors.NoSuchKey) as error:
      print(error.message)

      
  ```

  You can catch all `ClientError`s with `errors.ALL`.

  You can only use this style for error codes that work as Python property names.
  For error codes like EC2's `InvalidInstanceID.NotFound`, you have to use `catch_aws_error()` (see below).

  Unfortunately, you cannot get tab completion for error codes on the `errors` class, as a comprehensive list of error codes is not available as a Python package (`botocore` has a small number, but they are few and incomplete).

  Note that the value of `errors.NoSuchBucket` is not an exception class representing the `NoSuchBucket` error, it is an alias for `catch_aws_error('NoSuchBucket')`.
  It can only be used in an `except` statement; it will raise `RuntimeError` otherwise.
  You also cannot instantiate the `errors` class.


  The function takes as input error code(s), and optionally operation name(s), to match against the current raised exception. If the exception matches, the `except` block is executed.
  If your error handling still needs the error object, you can still use an `as` expression, otherwise it can be omitted (just `except catch_aws_error(...):`).
  Additionally, `catch_aws_error()` sets the fields from `AWSErrorInfo` (see below) directly on the `ClientError` object.

  ```python
  import boto3
  from aws_error_utils import catch_aws_error

  s3 = boto3.client('s3')
  try:
      s3.get_object(Bucket='my-bucket', Key='example')
  except catch_aws_error('NoSuchBucket') as error:
      print(error.message)

      
  ```

  You can provide error codes either as positional args, or as the `code` keyword argument with either as a single string or a list of strings.

  ```python
  catch_aws_error('NoSuchBucket')
  catch_aws_error(code='NoSuchBucket')

  catch_aws_error('NoSuchBucket', 'NoSuchKey')
  catch_aws_error(code=['NoSuchBucket', 'NoSuchKey'])
  ```

  If there are multiple API calls in the `try` block, and you want to match against specific ones, the `operation_name` keyword argument can help.
  Similar to the `code` keyword argument, the operation name(s) can be provided as either as a single string or a list of strings.

  ```python
  import boto3
  from aws_error_utils import catch_aws_error

  try:
      s3 = boto3.client('s3')
      s3.list_objects_v2(Bucket='bucket-1')
      s3.get_object(Bucket='bucket-2', Key='example')
  except catch_aws_error('NoSuchBucket', operation_name='GetObject') as error:
      
      
  ```

  You must provide an error code.
  To match exclusively against operation name, use the `aws_error_utils.ALL_CODES` token.
  For completeness, there is also an `ALL_OPERATIONS` token.

  ```python
  import boto3
  from aws_error_utils import catch_aws_error

  try:
      s3 = boto3.client('s3')
      s3.list_objects_v2(Bucket='bucket-1')
      s3.get_object(Bucket='bucket-1', Key='example')
  except catch_aws_error(ALL_CODES, operation_name='ListObjectsV2') as e:
      
  ```

  For more complex conditions, instead of providing error codes and operation names, you can provide a callable to evaluate the exception.
  Note that unlike error codes, you can only provide a single callable.

  ```python
  import re
  import boto3
  from aws_error_utils import catch_aws_error, get_aws_error_info

  def matcher(e):
      info = get_aws_error_info(e)
      return re.search('does not exist', info.message)

  try:
      s3 = boto3.client('s3')
      s3.list_objects_v2(Bucket='bucket-1')
  except catch_aws_error(matcher) as e:
      
      
  ```


  This function takes a returns an `AWSErrorInfo` object, which is a `collections.NamedTuple` with the following fields:

  * `code`
  * `message`
  * `http_status_code`
  * `operation_name`
  * `response` (the raw response dictionary)

  If you're not modifying your `except` statements to use `catch_aws_error()`, this function can be useful instead of remembering exactly how this information is stored in the `ClientError` object.

  If you're using `catch_aws_error()`, this function isn't necessary, because it sets these fields directly on the `ClientError` object.


  This is the matching logic behind `catch_aws_error()`.
  It takes a `ClientError`, with the rest of the arguments being error codes and operation names identical to `catch_aws_error()`, except that it does not support providing a callable.


  For testing, you can create `ClientError`s with the `make_aws_error()` function, which takes the following arguments:
  * `code` (required)
  * `message` (required)
  * `operation_name` (required)
  * `http_status_code`
  * `response`

  If a `response` dict is provided, it will be copied rather than modified.


pkgId: 2c5da49a5791538171263dd31e7a2ffea0c00830d0a1da84fe2fc321ceb2e0c4
name: python-aws-export-credentials
arch: src
version: 0.18.0
epoch: 0
release: 1
summary: Get AWS credentials from a profile to inject into other programs
url: https://github.com/benkehoe/aws-export-credentials
rpm_license: Apache-2.0
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-export-credentials-0.18.0-1.src.rpm
checksum_type: sha256
description:
  **Get AWS credentials from a profile to inject into other programs**

  > :warning: The AWS CLI now includes a command [`aws configure export-credentials`](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/configure/export-credentials.html) that covers the `--json`, `--env`, and `--env-export` options of `aws-export-credentials`, as well as providing env options for Windows.
  >
  > If you want to inject refreshable credentials into a locally-run container, [`imds-credential-server`](https://github.com/benkehoe/imds-credential-server) is a more focused solution for that.

  There are a number of other projects that extract AWS credentials and/or inject them into programs, but all the ones I've seen use the CLI's cache files directly, rather than leveraging boto3's ability to retrieve and refresh credentials.
  So I wrote this to do that.

  [boto3 (the AWS Python SDK)](https://boto3.amazonaws.com/v1/documentation/api/latest/index.html) has added support for loading credentials cached by [`aws sso login`](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/sso/login.html) as of [botocore version 1.17.0](https://github.com/boto/botocore/blob/develop/CHANGELOG.rst#1170).
  `aws-export-credentials` now requires boto3 >= 1.14.0, and so supports AWS SSO credentials as well.
  If all you want is AWS SSO support for an SDK other than Python, Go, or JavaScript (v3), take a look at [aws-sso-util](https://github.com/benkehoe/aws-sso-util#adding-aws-sso-support-to-aws-sdks), which can help you configure your profiles with a [credential process](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-sourcing-external.html) that doesn't require the credential injection process that `aws-export-credentials` does.



  I recommend you install [`pipx`](https://pipxproject.github.io/pipx/), which installs the tool in an isolated virtualenv while linking the script you need.

  ```bash

  pipx install aws-export-credentials


  python3 -m pip install --user aws-export-credentials


  aws-export-credentials
  {
    "Version": 1,
    "AccessKeyId": "<your access key here>",
    "SecretAccessKey": "<shhh it's your secret key>",
    "SessionToken": "<do you ever wonder what's inside the session token?>"
  }
  ```

  You can also download the Python file directly [here](https://raw.githubusercontent.com/benkehoe/aws-export-credentials/stable/aws_export_credentials/aws_export_credentials.py).



  Profiles work like in the AWS CLI (since it uses boto3); it will pick up the `AWS_PROFILE`
  or `AWS_DEFAULT_PROFILE` env vars, but the `--profile` argument takes precedence.


  ```
  aws-export-credentials --profile my-profile --json [--pretty]
  ```
  Print the credentials to stdout as a JSON object compatible with the `credential_process`
  spec. If `--pretty` is added, it'll be pretty-printed.


  ```
  aws-export-credentials --profile my-profile --env
  export $(aws-export-credentials --profile my-profile --env)
  eval $(aws-export-credentials --profile my-profile --env-export)
  ```
  Print the credentials as environment variables. With `--env-export`, the lines are prefixed
  by "`export `".


  ```
  aws-export-credentials --profile my-profile --exec echo 'my access key id is $AWS_ACCESS_KEY_ID'
  ```
  Execute the arguments after `--exec` using `os.system()`, injecting the credentials through
  environment variables.


  ```
  aws-export-credentials --profile my-profile --credentials-file-profile my-exported-profile
  aws-export-credentials --profile my-profile -c my-exported-profile
  ```
  Put the credentials in the given profile in your [shared credentials file](https://ben11kehoe.medium.com/aws-configuration-files-explained-9a7ea7a5b42e), which is typically `~/.aws/credentials` but can be controlled using the environment variable [`AWS_SHARED_CREDENTIALS_FILE`](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-envvars.html).


  There are two credential-serving options, `--imds` for a server presenting the EC2 IMDSv2 interface, and `--container` for a server presenting the ECS container metadata credentials interface.

  > :warning: If you want to inject refreshable credentials into a locally-run container, [imds-credential-server](https://github.com/benkehoe/imds-credential-server) is a more focused solution for that.


  You can use `--imds` to start a server, compliant with [the EC2 IMDSv2 endpoint](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html), that exports your credentials, and this can be used with containers.

  You provide `--imds` with a port (you can optionally provide the host part as well).

  If you're using docker, map the port from the host to the container, and set the environment variable `AWS_EC2_METADATA_SERVICE_ENDPOINT` to `http://host.docker.internal:MAPPED_PORT/` with the approporiate port and **remember to include the trailing slash.**

  AWS SDKs run inside the container should just work.
  ```bash

  $ aws-export-credentials --imds 8081


  $ docker run --rm -p 8081:8081 -e AWS_EC2_METADATA_SERVICE_ENDPOINT=http://host.docker.internal:8081/
  amazon/aws-cli sts get-caller-identity
  {
      "UserId": "AROAXXXXXXXXXXXXXXXXX:SessionName",
      "Account": "123456789012",
      "Arn": "arn:aws:sts::123456789012:assumed-role/SomeRole/SessionName"
  }
  ```


  > :warning: This method of providing credentials to containers doesn't work well. It only works on Linux using `--network host`. [On Mac](https://docs.docker.com/desktop/mac/networking/#use-cases-and-workarounds) and [Windows](https://docs.docker.com/desktop/windows/networking/#use-cases-and-workarounds), `--network host` is not available, the docker network is always separate. On all three, without `--network host` the host cannot be referenced as `localhost`, only as `host.docker.internal`, which is [not an allowed host the AWS SDKs](https://github.com/aws/aws-sdk/issues/562).

  You can use `--container` to start a server, compliant with the ECS metadata server, that exports your credentials, suitable for use with containers.

  You provide `--container` with a port (you can optionally provide the host part as well) and an authorization token.
  On your container, map the port from the server, set the `AWS_CONTAINER_CREDENTIALS_FULL_URI` environment variable to the URL as accessed inside the container, and set the `AWS_CONTAINER_AUTHORIZATION_TOKEN` environment variable to the same value you provided the server.

  You can use any value for the authorization, but it's best use a random value.

  ```bash

  AWS_CONTAINER_AUTHORIZATION_TOKEN=$(/proc/sys/kernel/random/uuid)


  aws-export-credentials --profile my-profile --container 8081 $AWS_CONTAINER_AUTHORIZATION_TOKEN &


  docker run --network host -e AWS_CONTAINER_CREDENTIALS_FULL_URI=http://localhost:8081 -e AWS_CONTAINER_AUTHORIZATION_TOKEN=$AWS_CONTAINER_AUTHORIZATION_TOKEN amazon/aws-cli sts get-caller-identity
  ```


  To avoid retrieving credentials every time when using `aws-export-credentials` with the same identity, you can cache the credentials in a file using the `--cache-file` argument.
  **Note `aws-export-credentials` does not distinguish in the cache between different identities. Different identities should use different cache files.**
  If you do not account for this, credentials may be loaded from the cache and exported that do not correspond to the credentials that would be exported without the cache.
  An example of a way to address this would be using a cache file named after the config profile you are exporting.

  Cache loading and saving fails silently, to ensure caching does not interrupt usage.
  If caching is not working, you can see the details with `--debug`.

  By default, cached credentials are considered expired if their expiration is less than 10 minutes in the future.
  You can change this value using the `--cache-expiration-buffer` argument, which takes a number of minutes.

  You can force the cache to refresh using `--refresh`.


  IAM Users and the account root have long-term credentials, which carry higher risk than temporary credentials.
  The [STS.GetSessionToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html) API call exists to provide temporary credentials based on these long-term credentials.
  If you pass the `--ensure-temporary` flag, it will use this API to get temporary credentials to export for an IAM User or account root.
  This process is always used for `--imds` and `--container`.


  In general, it's better to do role assumption by using profiles in `~/.aws/config` like this:

  ```ini

  [profile profile-to-call-assume-role-with]




  [profile my-assumed-role]
  role_arn = arn:aws:iam::123456789012:role/MyRole


  source_profile = profile-to-call-assume-role-with





  ```

  You can then use `my-assumed-role` like any other profile.
  It uses the AWS SDKs' built-in support for role assumption, rather than relying on third party code.
  It also gets you credential refreshing from the SDKs, where getting the credentials in the manner below cannot refresh them when they expire.

  You can then, if needed, export the assumed role credentials with `aws-export-credentials --profile my-assumed-role`.

  But if you absolutely must have ad hoc role assumption on the command line, you can accomplish that through [`aws-assume-role-lib`](https://github.com/benkehoe/aws-assume-role-lib#command-line-use).


pkgId: 799e33e5dd3628ed256af5b6bd66117895a538d7cb9ab29d09f5eb334f2d875a
name: python-aws-feature-store
arch: src
version: 0.0.17
epoch: 0
release: 1
summary: Simplified SageMaker Feature Store
url: https://github.com/bilykigor/aws_feature_store
rpm_license: Apache License 2.0
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-feature-store-0.0.17-1.src.rpm
checksum_type: sha256
description:
  Use the package manager [pip](https://pip.pypa.io/en/stable/) to install foobar.
  ```bash
  pip install aws_feature_store
  ```


pkgId: fa268d703c5bd4cb393be34150ee123d8be9529f11f824b4ff54efae375da4d0
name: python-aws-fortuna
arch: src
version: 0.1.45
epoch: 0
release: 1
summary: A Library for Uncertainty Quantification.
url: https://pypi.org/project/aws-fortuna/
rpm_license: Apache-2.0
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-fortuna-0.1.45-1.src.rpm
checksum_type: sha256
description:
  Proper estimation of predictive uncertainty is fundamental in applications that involve critical decisions.
  Uncertainty can be used to assess reliability of model predictions, trigger human intervention,
  or decide whether a model can be safely deployed in the wild.
  Fortuna is a library for uncertainty quantification that makes it easy for users to run benchmarks and bring uncertainty to production systems.
  Fortuna provides calibration and conformal methods starting from pre-trained models written in any framework,
  and it further supports several Bayesian inference methods starting from deep learning models written in `Flax <https://flax.readthedocs.io/en/latest/index.html>`_.
  The language is designed to be intuitive for practitioners unfamiliar with uncertainty quantification,
  and is highly configurable.
  Check the `documentation <https://aws-fortuna.readthedocs.io/en/latest/>`_ for a quickstart, examples and references.


pkgId: 71a97050c0e9628f4002cbb9e42a6c241cb7d4117e9719542433637868ca2a49
name: python-aws-fsx-lifecycle-status-monitor
arch: src
version: 0.0.24
epoch: 0
release: 1
summary: aws-fsx-lifecycle-status-monitor
url: https://stefanfreitag.github.io/AWS-FSx-Lifecycle-Status-Monitor
rpm_license: Apache-2.0
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-fsx-lifecycle-status-monitor-0.0.24-1.src.rpm
checksum_type: sha256
description:
  The documentation is available [here](https://stefanfreitag.github.io/AWS-FSx-Lifecycle-Status-Monitor/).





  * Execute the unit tests under `./test`

    ```shell
    yarn test
    ```
  * Execute integration tests under `.integ-tests`

    ```shell
    yarn integ-runner --directory ./integ-tests  --update-on-failed --parallel-regions eu-central-1
    ```


pkgId: 095a883fbcdfe742999625042429c9595984db9a606e8f5ca2d8ad2f45d36aef
name: python-aws-glue-schema-registry
arch: src
version: 1.1.3
epoch: 0
release: 1
summary: Use the AWS Glue Schema Registry.
url: https://pypi.org/project/aws-glue-schema-registry/
rpm_license: Apache Software License
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-glue-schema-registry-1.1.3-1.src.rpm
checksum_type: sha256
description:
  [![PyPI](https://img.shields.io/pypi/v/aws-glue-schema-registry.svg)](https://pypi.org/project/aws-glue-schema-registry)
  [![PyPI](https://img.shields.io/pypi/pyversions/aws-glue-schema-registry)](https://pypi.org/project/aws-glue-schema-registry)
  [![main](https://github.com/DisasterAWARE/aws-glue-schema-registry-python/actions/workflows/main.yml/badge.svg)](https://github.com/DisasterAWARE/aws-glue-schema-registry-python/actions/workflows/main.yml)

  Use the AWS Glue Schema Registry in Python projects.

  This library is a partial port of [aws-glue-schema-registry](https://github.com/awslabs/aws-glue-schema-registry) which implements a subset of its features with full compatibility.



  Feature | Java Library | Python Library | Notes
  :------ | :----------- | :------------- | :----
  Serialization and deserialization using schema registry | ✔️ | ✔️
  Avro message format | ✔️ | ✔️
  JSON Schema message format | ✔️ | ✔️
  Kafka Streams support | ✔️ | | N/A for Python, Kafka Streams is Java-only
  Compression | ✔️ | ✔️ |
  Local schema cache | ✔️ | ✔️
  Schema auto-registration | ✔️ | ✔️
  Evolution checks | ✔️ | ✔️
  Migration from a third party Schema Registry | ✔️ | ✔️
  Flink support | ✔️ | ❌
  Kafka Connect support | ✔️ | | N/A for Python, Kafka Connect is Java-only



  Clone this repository and install it:

  ```
  python setup.py install -e .
  ```

  This library includes opt-in extra dependencies that enable support for certain features. For example, to use the schema registry with [kafka-python](https://pypi.org/project/kafka-python/), you should install the `kafka-python` extra:

  ```
  python setup.py install -e .[kafka-python]
  ```

  Extra name | Purpose
  :--------- | :------
  kafka-python | Provides adapter classes to plug into `kafka-python`



  First use `boto3` to create a low-level AWS Glue client:

  ```python
  import boto3


  session = boto3.Session(access_key_id=xxx, secret_access_key=xxx, region_name='us-west-2')

  glue_client = session.client('glue')
  ```

  See https://boto3.amazonaws.com/v1/documentation/api/latest/guide/quickstart.html#configuration for more information on configuring boto3.

  Send Kafka messages with `SchemaRegistrySerializer`:

  ```python
  from aws_schema_registry import DataAndSchema, SchemaRegistryClient
  from aws_schema_registry.avro import AvroSchema




  from aws_schema_registry.adapter.kafka import KafkaSerializer
  from kafka import KafkaConsumer


  client = SchemaRegistryClient(glue_client,
                                registry_name='my-registry')


  serializer = KafkaSerializer(client)


  producer = KafkaProducer(value_serializer=serializer)



  with open('user.avsc', 'r') as schema_file:
      schema = AvroSchema(schema_file.read())


  data = {
      'name': 'John Doe',
      'favorite_number': 6
  }
  producer.send('my-topic', value=(data, schema))

  ```

  Read Kafka messages with `SchemaRegistryDeserializer`:

  ```python
  from aws_schema_registry import SchemaRegistryClient




  from aws_schema_registry.adapter.kafka import KafkaDeserializer
  from kafka import KafkaConsumer


  client = SchemaRegistryClient(glue_client,
                                registry_name='my-registry')


  deserializer = KafkaDeserializer(client)


  consumer = KafkaConsumer('my-topic', value_deserializer=deserializer)


  for message in consumer:
      
      value: DataAndSchema = message.value
      
      value.data == value[0]
      value.schema == value[1]
      
      data, schema = value
  ```



  Clone this repository and install development dependencies:

  ```
  pip install -e .[dev]
  ```

  Run the linter and tests with tox before committing. After committing, check Github Actions to see the result of the automated checks.



  Lint the code with:

  ```
  flake8
  ```

  Run the type checker with:

  ```
  mypy
  ```



  Tests go under the `tests/` directory. All tests outside of `tests/integration` are unit tests with no external dependencies.

  Tests under `tests/integration` are integration test that interact with external resources and/or real AWS schema registries. They generally run slower and require some additional configuration.

  Run just the unit tests with:

  ```
  pytest --ignore tests/integration
  ```

  All integration tests use the following environment variables:

  - `AWS_ACCESS_KEY_ID`
  - `AWS_SECRET_ACCESS_KEY`
  - `AWS_SESSION_TOKEN`
  - `AWS_REGION`
  - `AWS_PROFILE`
  - `CLEANUP_REGISTRY`: Set to any value to prevent the test from destroying the registry created during the test, allowing you to inspect its contents.

  If no `AWS_` environment variables are set, `boto3` will try to load credentials from your default AWS profile.

  See individual integration test directories for additional requirements and setup instructions.



  This project uses [Tox](https://tox.wiki/en/latest/) to run tests across multiple Python versions.

  Install Tox with:

  ```
  pip install tox
  ```

  and run it with:

  ```
  tox
  ```

  Note that Tox requires the tested python versions to be installed. One convenient way to manage this is using [pyenv](https://github.com/pyenv/pyenv#installation). See the `.python-versions` file for the Python versions that need to be installed.




  Assuming pypi permissions:

  ```
  python -m build
  twine upload -r testpypi dist/*
  twine upload dist/*
  ```


pkgId: 7204a52f83bb166b8be65ee586dd54d2460889e55e4c0f9a38f8d37c89a71422
name: python-aws-google-auth
arch: src
version: 0.0.38
epoch: 0
release: 1
summary: Acquire AWS STS (temporary) credentials via Google Apps SAML Single Sign On
url: https://github.com/cevoaustralia/aws-google-auth
rpm_license: MIT
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-google-auth-0.0.38-1.src.rpm
checksum_type: sha256
description:
  |github-badge| |docker-badge| |pypi-badge| |coveralls-badge|
  This command-line tool allows you to acquire AWS temporary (STS)
  credentials using Google Apps as a federated (Single Sign-On, or SSO)
  provider.


pkgId: 1fc59d90355e07d7062b61fe99e18a80d73f0a7f9a352b664f5f4718c68821d7
name: python-aws-hexagonal-adapters
arch: src
version: 1.3.2
epoch: 0
release: 1
summary: Adapters following hexagonal architecture to connect various AWS services.
url: https://pypi.org/project/aws-hexagonal-adapters/
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-hexagonal-adapters-1.3.2-1.src.rpm
checksum_type: sha256
description:
  [![auto-merge](https://github.com/airmonitor/aws-hexagonal-adapters/actions/workflows/auto_merge.yml/badge.svg)](https://github.com/airmonitor/aws-hexagonal-adapters/actions/workflows/auto_merge.yml)
  [![tests](https://github.com/airmonitor/aws-hexagonal-adapters/actions/workflows/tests.yml/badge.svg)](https://github.com/airmonitor/aws-hexagonal-adapters/actions/workflows/tests.yml)


  Adapters following hexagonal architecture to connect various AWS services






  ```python
  from os import environ

  from aws_hexagonal_adapters.s3_service import S3Service

  S3_SERVICE = S3Service(region_name=environ["CURRENT_REGION"])


  S3_SERVICE.download(
      bucket="bucket_name", local_path=f"/tmp/object", remote_path="object"
  )
  ```


  ```python
  from os import environ

  from aws_hexagonal_adapters.s3_service import S3Service

  S3_SERVICE = S3Service(region_name=environ["CURRENT_REGION"])


  S3_SERVICE.upload(
      bucket="bucket_name",
      local_path=f"/tmp/object_name",
      remote_path="object_name",
      extra_args={"StorageClass": "STANDARD_IA"},
  )
  ```


  ```python
  from os import environ

  from aws_hexagonal_adapters.s3_service import S3Service

  S3_SERVICE = S3Service(region_name=environ["CURRENT_REGION"])


  S3_SERVICE.list_files(bucket="bucket_name", prefix="folder_name")
  ```


  ```python
  from os import environ

  from aws_hexagonal_adapters.s3_service import S3Service

  S3_SERVICE = S3Service(region_name=environ["CURRENT_REGION"])


  S3_SERVICE.delete_object(bucket="bucket_name", key="object_name")
  ```


  ```python
  from os import environ

  from aws_hexagonal_adapters.s3_service import S3Service

  S3_SERVICE = S3Service(region_name=environ["CURRENT_REGION"])
  objects = ["folder/object1.txt", "folder/object2.txt", "folder/object3.txt"]

  S3_SERVICE.delete_objects(bucket="bucket_name", keys=objects)
  ```



  ```python
  from os import environ

  from aws_hexagonal_adapters.dynamo_db_service import DynamoDBService

  DYNAMODB_SERVICE = DynamoDBService(region_name=environ["REGION_NAME"])

  item = DYNAMODB_SERVICE.get_item(
      table_name=environ["DYNAMODB_TABLE_NAME"],
      key={"pk": f'{environ["DYNAMODB_TABLE_ITEM_NAME"]}', "sk": "1"},
  )
  ```

  ```python
  from os import environ

  from boto3.dynamodb.conditions import Key

  from aws_hexagonal_adapters.dynamo_db_service import DynamoDBService

  DYNAMODB_SERVICE = DynamoDBService(region_name=environ["REGION_NAME"])

  item = DYNAMODB_SERVICE.get_items(
      table_name=environ["DYNAMODB_TABLE_NAME"],
      filter_expression=Key("sk").eq("2"),
  )
  ```


  ```python
  from os import environ

  from aws_hexagonal_adapters.dynamo_db_service import DynamoDBService

  DYNAMODB_SERVICE = DynamoDBService(region_name=environ["REGION_NAME"])

  item = DYNAMODB_SERVICE.scan_items(
      table_name=environ["DYNAMODB_TABLE_NAME"],
      index_name=environ["DYNAMODB_INDEX_NAME"],
  )
  ```


  ```python
  from os import environ

  from aws_hexagonal_adapters.sqs_service import SQSService

  SQS_SERVICE = SQSService(region_name=environ["REGION_NAME"])

  messages = SQS_SERVICE.receive_messages(queue_url=environ["SQS_QUEUE_NAME"])
  ```

rpm_license:
  MIT License  Copyright (c) 2023 Tomasz Szuster  Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:  The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.  THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.


pkgId: 8b3234e3914851dc244d62d807bf35512fbea105b1bd6a81c43ed1021bffd2ed
name: python-aws-hotel-helpers
arch: src
version: 0.3.0
epoch: 0
release: 1
summary: AWS helper utilities for hotel management systems
url: https://github.com/yourusername/aws-hotel-helpers
rpm_license: None
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-hotel-helpers-0.3.0-1.src.rpm
checksum_type: sha256
description:
  A Python library that simplifies AWS operations for hotel management systems. This package provides easy-to-use helpers for S3 file storage, SNS notifications, and other AWS services commonly used in hotel management applications.



  Install the package using pip:

  ```bash
  pip install aws-hotel-helpers
  ```



  Here's a simple example of how to use the package:

  ```python
  from aws_hotel_helpers import AWSHelper


  aws_helper = AWSHelper(region_name='us-east-1')


  try:
      image_url = aws_helper.upload_image(
          image_file,
          bucket_name='my-hotel-images'
      )
      print(f"Image uploaded successfully: {image_url}")
  except Exception as e:
      print(f"Error uploading image: {str(e)}")


  booking_data = {
      'booking_id': '12345',
      'user_email': 'guest@example.com',
      'hotel_name': 'Luxury Hotel',
      'check_in': '2024-04-01',
      'check_out': '2024-04-05',
      'total_price': '500.00'
  }

  aws_helper.send_booking_notification(
      'arn:aws:sns:us-east-1:123456789012:BookingNotifications',
      booking_data
  )
  ```



  - Simple S3 file upload with automatic content type detection
  - SNS notification sending for booking confirmations
  - Automatic credential management
  - Comprehensive error handling



  For more detailed documentation and examples, visit our [GitHub repository](https://github.com/yourusername/aws-hotel-helpers).



  This project is licensed under the MIT License - see the LICENSE file for details.


pkgId: 4cc18a8f9d82bff1fbeb3faaf39df5cb459f81706e26627dfcb0a47c33b956bf
name: python-aws-insurancelake-etl
arch: src
version: 4.1.3
epoch: 0
release: 1
summary: A CDK Python app for deploying ETL jobs that operate data pipelines for InsuranceLake in AWS
url: https://github.com/aws-samples/aws-insurancelake-etl
rpm_license: MIT-0
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-insurancelake-etl-4.1.3-1.src.rpm
checksum_type: sha256
description:
  This section focuses on the overall InsuranceLake architecture and the components of the ETL.

  As shown in the figure below, we use S3 for storage, specifically three different S3 buckets:
  1. Collect bucket to store raw data in its original format.
  1. Cleanse/Curate bucket to store the data that meets the quality and consistency requirements for the data source.
  1. Consume bucket for data that is used by analysts and data consumers (for example, Amazon Quicksight, Amazon Sagemaker).
  InsuranceLake is designed to support a number of source systems with different file formats and data partitions. To demonstrate, we have provided a CSV parser and sample data files for a source system with two data tables, which are uploaded to the Collect bucket.
  We use Lambda and Step Functions for orchestration and scheduling of ETL workloads. We then use AWS Glue with PySpark for ETL and data cataloging, DynamoDB for transformation persistence, and Athena for interactive queries and analysis. We use various AWS services for logging, monitoring, security, authentication, authorization, notification, build, and deployment.
  **Note:** [AWS Lake Formation](https://aws.amazon.com/lake-formation/) is a service that makes it easy to set up a secure data lake in days. [Amazon QuickSight](https://aws.amazon.com/quicksight/) is a scalable, serverless, embeddable, machine learning-powered business intelligence (BI) service built for the cloud. [Amazon DataZone](https://aws.amazon.com/datazone/) is a data management service that makes it faster and easier for customers to catalog, discover, share, and govern data stored across AWS, on premises, and third-party sources. These three services are not used in this solution but can be added.
  ![Conceptual Data Lake](https://raw.githubusercontent.com/aws-solutions-library-samples/aws-insurancelake-etl/main/docs/Aws-cdk-insurancelake-data_lake.png)

  The figure below represents the ETL resources we provision for the data lake.
  ![InsuranceLake ETL Architecture](https://raw.githubusercontent.com/aws-solutions-library-samples/aws-insurancelake-etl/main/docs/Aws-cdk-insurancelake-etl.png)
  1. A file server uploads files to the Collect bucket of InsuranceLake; file server is a data producer or source for the data lake.
  1. S3 triggers an ObjectCreated event notification to Lambda function.
  1. The Lambda function inserts job information in an DynamoDB table.
  1. The Lambda function starts an execution of Step Functions State machine.
  1. This step runs the first AWS Glue job: initiates data processing from Collect to Cleanse.
  1. An AWS Glue job will process the data from Collect to Cleanse; source data is assumed to be in CSV format and will be converted to Parquet format.
  1. DynamoDB stores original values from PII tokenization, and provides lookup data to the AWS Glue job.
  1. After creating Apache Parquet data, the job updates the AWS Glue Data Catalog table.
  1. In this step the second AWS Glue job initiates data processing from Cleanse to Consume.
  1. The AWS Glue Cleanse to Consume job fetches data transformation rules from AWS Glue etl-scripts bucket, and runs transformations.
  1. The AWS Glue job stores prepared data in Apache Parquet format in the Consume bucket.
  1. The AWS Glue job updates the AWS Glue Data Catalog table.
  1. The AWS Glue job updates the DynamoDB table with job status.
  1. Step Functions sends an SNS notification.


pkgId: 5d9f745d31a29f18e4f06a1bfc3615ca1806dd79a9e553dc77d40de88cca400e
name: python-aws-jmespath-utils
arch: src
version: 1.1.0
epoch: 0
release: 1
summary: jmespath custom functions for filtering and excluding AWS resources by tag
url: https://pypi.org/project/aws-jmespath-utils/
rpm_license: Apache-2.0
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-jmespath-utils-1.1.0-1.src.rpm
checksum_type: sha256
description:
  ```bash
  pip3 install aws_jmespath_utils
  ```



  Check out the example code:

  - [examples/01_filter_tags_basic.py](./examples/01_filter_tags_basic.py)
  - [examples/02_filter_tags_exclude.py](./examples/02_filter_tags_exclude.py)



  **Find resources with 'Name' tag set**

  ```python
  jmespath.search(  # it's important that your expression array must be inside `` backticks
      '[] | filter_tags(`["Name=*"]`, @)', data_list, options=jmespath_options
  )
  ```

  **Find tag values starting with 123**

  ```python
  jmespath.search(  # it's important that your expression array must be inside `` backticks
      '[].filter_tags(`["=123*"]`, @)', data_list, options=jmespath_options
  )
  ```

  **Find Many tag values**

  ```python
  jmespath.search(  # it's important that your expression array must be inside `` backticks
      '[].filter_tags(`["=123*", "=jmespath*"]`, @)', data_list, options=jmespath_options
  )
  ```

  **Exclude Tags**

  ```python
  jmespath.search(  # it's important that your expression array must be inside `` backticks
      '[].exclude_tags(`["map-migrated=*"]`, @)', data_list, options=jmespath_options
  )
  ```

  **Setting log levels**

  ```bash

  export AWS_JMESPATH_UTILS_LOG_LEVEL="DEBUG"
  export AWS_JMESPATH_UTILS_LOG_LEVEL="INFO"  # default
  ```





  ```python
  import jmespath
  from aws_jmespath_utils import jmespath_options
  import json
  data_list = [
      {"a": "a", "Tags": [{"Key": "Name", "Value": "jmespath-utils"}, ]},
      {"b": "b", "Tags": [{"Key": "Nam", "Value": "jmespath-utils-nam"}]},
      {"c": "c", "Tags": [{"Key": "map-migrated", "Value": "234"}]}
  ]

  print(
      json.dumps(
          jmespath.search('[] | filter_tags(`["Name=*"]`, @)', data_list, options=jmespath_options),
          indent=2
      )
  )

  print(
      json.dumps(
          jmespath.search('[] | exclude_tags(`["Nam*="]`, @)', data_list, options=jmespath_options),
          indent=2
      )
  )

  ```


pkgId: 844d9a532f7245a783b665bf4948cc29d96a34e63ea100154de7f9b80f9fcd11
name: python-aws-json-term-matcher
arch: src
version: 0.1.5
epoch: 0
release: 1
url: https://pypi.org/project/aws-json-term-matcher/
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-json-term-matcher-0.1.5-1.src.rpm
checksum_type: sha256
summary:
  A Python library for advanced filtering and matching of AWS JSON logs, designed to simplify log parsing and enhance filtering capabilities.

description:
  `aws_json_term_matcher` is a Python package designed to parse and evaluate filter expressions, such as those found in AWS CloudWatch log filters. This tool uses **Lark** for PEG parsing and supports logical operations like `AND`, `OR`, and parentheses for grouping.


  - Parses logical expressions from JSON filters
  - Supports `&&` (AND), `||` (OR), and parentheses for nested expressions
  - Extensible to include evaluation and tree reduction (future updates)



  Clone the repository and install the requirements:

  ```bash
  pip install aws-json-term-matcher
  ```




  This tool provides enhanced JSON term matching for logs, giving you more flexibility and functionality when working with CloudWatch Logs. It allows you to use more sophisticated filters to search through JSON log events, making your log filtering more efficient.

  The key improvement is the ability to filter logs with patterns similar to those used in AWS CloudWatch Logs but with more powerful Python-based features.



  ```python
  from aws_json_term_matcher.matcher import match


  log = {
      "eventType": "UpdateTrail",
      "bandwidth": 80,
      "latency": 45,
      "number": [0.001, 1000],
      "sourceIPAddress": "123.123.1.1",
      "resources": [
          "arn:aws:states:us-east-1:111222333444:execution:OrderProcessorWorkflow:d57d4769-72fd",
          "arn:aws:states:us-east-1:111222333444:stateMachine:OrderProcessorWorkflow"
      ]
  }


  filter_str = '{ $.bandwidth > 75 }'



  if match(log, filter_str):
      print("Log matches the filter!")
  else:
      print("Log does not match.")
  ```
  In this example, the tool filters a log based on bandwidth and latency values, similar to how AWS CloudWatch Logs filters JSON log events.


  For more information about the original JSON term matching feature in AWS CloudWatch Logs, check out the [official AWS documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/FilterAndPatternSyntax.html#matching-terms-json-log-events).

rpm_license:
  Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at  http://www.apache.org/licenses/LICENSE-2.0  Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.


pkgId: 19fc75c363080f360011d84f79a5b6f68c24e948160b353e505782fd877c4708
name: python-aws-kinesis-agg
arch: src
version: 1.2.3
epoch: 0
release: 1
url: http://github.com/awslabs/kinesis-aggregation
rpm_license: Apache-2.0
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-kinesis-agg-1.2.3-1.src.rpm
checksum_type: sha256
summary:
  Python module to assist in taking advantage of the Kinesis message aggregation format for both aggregation and deaggregation.

description:
  Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
  Licensed under the Apache License, Version 2.0 (the "License");
  you may not use this file except in compliance with the License.
  You may obtain a copy of the License at
     http://www.apache.org/licenses/LICENSE-2.0
  Unless required by applicable law or agreed to in writing, software
  distributed under the License is distributed on an "AS IS" BASIS,
  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  See the License for the specific language governing permissions and
  limitations under the License.


pkgId: 929d48bdc9b95619ffd1011ccb5bd5592949050cc6e2a1d136a83218e424adf4
name: python-aws-kommandos
arch: src
version: 1.0.14
epoch: 0
release: 1
summary: Advisory Infrastructure Setup Toolset - The Python Package
url: https://github.com/derstolz/aws-kommandos
rpm_license: MIT License
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-kommandos-1.0.14-1.src.rpm
checksum_type: sha256
description:
  Advisory Infrastructure Setup Scripts



  Have you ever been bothered with setting up your C2 infrastructure on AWS prior to/during a red team engagement? Having
  to deal with logging in, configuring security groups, going through the process of creating DNS record sets and such?

  If you hate doing this time after time and just wanna have a script that does everything for you - you've come to the
  right place.

  AWS Kommandos automates the process of creating cloud instances for various purposes - as C2 servers, for example. It
  also helps you to manage your AWS console - from changing firewall rules and managing your SSH access keys to adjusting
  the DNS record sets. All in one damn script.

  You're only expected to create an AWS account and configure the access keys for running Kommandos locally.

  See the Usage section for getting an idea how to use it.

  Kommandos automatically creates its directory under the ~/.aws-kommandos path to store SSH private keys it creates.





  ```bash
  apt install python3 python3-pip
  pip3 install aws-kommandos
  ```



  The first option is to use the *awscli* client to configure your AWS credentials used by Kommandos.
  `aws configure`

  The second options is to export the AWS credentials as environment variables
  ```bash
  export AWS_ACCESS_KEY_ID=key_id
  export AWS_ACCESS_KEY_SECRET=secret
  export AWS_REGION=region
  ```

  The third option is to use the command-line arguments to pass credentials to Kommandos
  `aws-kommandos --access-key-id <key_id> --access-key-secret <secret> --region-name <region>`





  `aws-kommandos --help`

  `aws-kommandos -h`



  `aws-kommandos --stats`



  `aws-kommandos --stats --verbose`

  `aws-kommandos --stats -v`



  ```text
  ╰$ aws-kommandos --terminate-all
  Terminating all running instances
  Terminating i-0df15af122876dd62
  ```



  ```text
  ╰$ aws-kommandos --search-ami "ubuntu*server*20.04*"
  {'CreationDate': '2021-07-27T16:45:08.000Z',
   'ImageId': 'ami-06e715bf46b6caf71',
   'State': 'available',
   'Name': 'ubuntu-pro-server/images/hvm-ssd/ubuntu-focal-20.04-amd64-pro-serve-ae7ed378-8838-4fcf-842d-d1d09b34f116-ami-005f184e361f78579.4',
   'ImageLocation': 'aws-marketplace/ubuntu-pro-server/images/hvm-ssd/ubuntu-focal-20.04-amd64-pro-serve-ae7ed378-8838-4fcf-842d-d1d09b34f116-ami-005f184e361f78579.4',
   'Description': 'Canonical, Ubuntu Server Pro, 20.04 LTS, amd64 focal image '
                  'build on 2021-07-20',
   'ImageOwnerAlias': 'aws-marketplace'}
  1 AMI images found
  ```



  ```text
  ╰$ aws-kommandos --security-group sg-66666666661488666 --start
  Creating a new SSH key pair: proxy-key
  The SSH key pair with the name 'proxy-key' already exists
  Starting a new instance: ami-0746eb3cb5c684ae6 proxy-key sg-030abb524637009f3 t2.micro proxy-instance
  The instance has been created
  Waiting for the server boot...
  The server is up and running at 18.197.229.100
  Waiting until the SSH service is available...
  The default user of the AMI 'ami-0746eb3cb5c684ae6' has been identified as 'ubuntu'
  Use the following command for connecting to the instance: ssh ubuntu@18.197.229.100 -i proxy-key.pem
  ```

  Oh, and did I mention that if you don't have an SSH access key the script automatically creates one for you?
  Use *--force-recreate-key* to force the script into creating a new key even if one with the same name exists.


  This command starts a new instance and uses the domain name supplied with the *--fqdn* argument
  to create A and MX record sets pointing to the IP address of the newly created EC2 instance.
  ```text
  ╰$ aws-kommandos --security-group sg-66666666661488666 --start --link-fqdn --fqdn virtualsquad.ninja
  Creating a new SSH key pair: proxy-key
  The SSH key pair with the name 'proxy-key' already exists
  Starting a new instance: ami-0746eb3cb5c684ae6 proxy-key sg-030abb524637009f3 t2.micro proxy-instance
  The instance has been created
  Waiting for the server boot...
  The server is up and running at 18.184.218.238
  Waiting until the SSH service is available...
  The default user of the AMI 'ami-0746eb3cb5c684ae6' has been identified as 'ubuntu'
  Use the following command for connecting to the instance: ssh ubuntu@18.184.218.238 -i proxy-key.pem
  A new record set virtualsquad.ninja. A 18.184.218.238 has been created
  A new record set virtualsquad.ninja. MX 1 18.184.218.238 has been created
  ```


  ```text
  ╰$ aws-kommandos --security-group sg-66666666661488666 --allow-inbound 443/tcp:0.0.0.0/0
  Authorizing ingress '[443/tcp -> 0.0.0.0/0] - ' on 'sg-66666666661488666'
  Operation performed successfully
  ```


  ```text
  ╰$ aws-kommandos --security-group sg-66666666661488666 --delete-inbound 443/tcp:0.0.0.0/0
  Revoking ingress '[443/tcp -> 0.0.0.0/0] - ' on 'sg-66666666661488666'
  Operation performed successfully
  ```


  ```text
  ╰$ aws-kommandos --security-group sg-66666666661488666 --allow-outbound 443/tcp:0.0.0.0/0
  Authorizing egress '[443/tcp -> 0.0.0.0/0] - ' on 'sg-66666666661488666'
  Operation performed successfully
  ```


  ```text
  ╰$ aws-kommandos --security-group sg-66666666661488666 --delete-outbound 443/tcp:0.0.0.0/0
  Revoking egress '[443/tcp -> 0.0.0.0/0] - ' on 'sg-66666666661488666'
  Operation performed successfully
  ```


  ```text
  ╰$ aws-kommandos --create-security-group NinjaGroup
  A new security group with the name 'NinjaGroup' has been created
  ```


  ```text
  ╰$ aws-kommandos --create-security-group "NinjaGroup: My Awesome Security Group"
  A new security group with the name 'NinjaGroup' has been created
  ```


  ```text
  ╰$ aws-kommandos --delete-security-group --security-group-id sg-0b2d1b55354c531bd
  The security group with id 'sg-0b2d1b55354c531bd' has been deleted
  ```


  ```text
  ╰$ aws-kommandos --fqdn virtualsquad.ninja --add-record --record-type A --record-value 55.55.55.55
  A new record set virtualsquad.ninja. A 55.55.55.55 has been created
  ```


  ```text
  ╰$ aws-kommandos --fqdn virtualsquad.ninja --delete-record --record-type A --record-value 55.55.55.55
  The record set virtualsquad.ninja. A 55.55.55.55 has been deleted
  ```

  And many more! Please use --help to see what else you could do with Kommandos.


pkgId: 62824348820dcd8a75b1f11c673d41d098718b264b2e99f0675b02e32806c269
name: python-aws-lambda-builders
arch: src
version: 1.50.0
epoch: 0
release: 1
summary: Python library to compile, build & package AWS Lambda functions for several runtimes & frameworks.
url: https://github.com/awslabs/aws-lambda-builders
rpm_license: Apache License 2.0
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-lambda-builders-1.50.0-1.src.rpm
checksum_type: sha256
description:
  ![Apache 2.0 License](https://img.shields.io/github/license/aws/aws-lambda-builders)
  ![GitHub release (latest by date)](https://img.shields.io/github/v/release/aws/aws-lambda-builders)
  ![PyPI - Python Version](https://img.shields.io/pypi/pyversions/aws-lambda-builders)
  ![pip](https://img.shields.io/badge/pip-aws--lambda--builders-9cf)

  Lambda Builders is a Python library to compile, build and package AWS Lambda functions for several runtimes &
  frameworks.

  Lambda Builders currently contains the following workflows

  * Java with Gradle
  * Java with Maven
  * Dotnet with amazon.lambda.tools
  * Python with Pip
  * Javascript with Npm
  * Typescript with esbuild
  * Ruby with Bundler
  * Go with Mod
  * Rust with Cargo

  In Addition to above workflows, AWS Lambda Builders also supports *Custom Workflows* through a Makefile.

  Lambda Builders is the brains behind the `sam build` command from [AWS SAM CLI](https://github.com/awslabs/aws-sam-cli)



  Lambda Builders is a Python library.
  It additionally exposes a JSON-RPC 2.0 interface to use from other languages.

  If you intend to integrate with Lambda Builders,
  check out [this section of the DESIGN DOCUMENT](DESIGN.md#builders-library).



  If you are a developer and interested in contributing, read the [DESIGN DOCUMENT](./DESIGN.md) to understand how this works.


pkgId: 9bfd41a48e7eb06c6f8daacddeaff1aebceec9aa7740d7a313e2cd24e40cfa58
name: python-aws-lambda-ci
arch: src
version: 0.0.8
epoch: 0
release: 1
summary: Continuous integration pipeline for aws lambda function
url: https://github.com/kodless/aws-lambda-ci
rpm_license: Apache License 2.0
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-lambda-ci-0.0.8-1.src.rpm
checksum_type: sha256
description:
  The user/role that call this pipeline should have these permissions attached to it.
      {
          "Version": "2012-10-17",
          "Statement": [
              {
                  "Sid": "",
                  "Effect": "Allow",
                  "Action": [
                      "s3:ListBucket",
                      "s3:GetObject"
                  ],
                  "Resource": [
                      "arn:aws:s3:::artifacts-bucket-name/*",
                      "arn:aws:s3:::artifacts-bucket-name"
                  ]
              },
              {
                  "Sid": "",
                  "Effect": "Allow",
                  "Action": [
                      "s3:PutObject",
                      "s3:GetObject"
                  ],
                  "Resource": [
                      "arn:aws:s3:::artifacts-bucket-name/lambda-ci/function-name/*",
                      "arn:aws:s3:::artifacts-bucket-name/lambda-ci/function-name"
                  ]
              },
              {
                  "Sid": "",
                  "Effect": "Allow",
                  "Action": [
                      "lambda:UpdateFunctionConfiguration",
                      "lambda:UpdateFunctionCode",
                      "lambda:UpdateAlias",
                      "lambda:PublishVersion",
                      "lambda:GetFunction"
                  ],
                  "Resource": "arn:aws:lambda:us-east-1:YOUR_ACCOUNT_ID:function:function-name"
              },
              {
                  "Sid": "",
                  "Effect": "Allow",
                  "Action": [
                      "lambda:PublishLayerVersion",
                      "Lambda:ListLayerVersions"
                  ],
                  "Resource": "arn:aws:lambda:us-east-1:YOUR_ACCOUNT_ID:layer:function-layer-name"
              },
              {
                  "Sid": "",
                  "Effect": "Allow",
                  "Action": "lambda:GetLayerVersion",
                  "Resource": "arn:aws:lambda:us-east-1:YOUR_ACCOUNT_ID:layer:function-layer-name:*"
              }
          ]
      }


pkgId: 6847712c07a80c329048eb02bc805722ba727ef4200c7dd8f8023380548435e6
name: python-aws-lambda-decorators
arch: src
version: 0.53
epoch: 0
release: 1
summary: A set of python decorators to simplify aws python lambda development
url: https://github.com/gridsmartercities/aws-lambda-decorators
rpm_license: MIT
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-lambda-decorators-0.53-1.src.rpm
checksum_type: sha256
description:
  [<img align="right" alt="Grid Smarter Cities" src="https://s3.eu-west-2.amazonaws.com/open-source-resources/grid_smarter_cities_small.png">](https://www.gridsmartercities.com/)

  ![Build Status](https://codebuild.eu-west-2.amazonaws.com/badges?uuid=eyJlbmNyeXB0ZWREYXRhIjoiSTZNdEsxUHdnWWdRMGwrS3FuaUxSb0g5c2hNdWdSNE94Y1RFRGNrdk96Zm9LWlZWWmpEK1FTWmcraGRnMEdzbmRjakF5SDVQUVBzcVpNL3hLSGw3TnpNPSIsIml2UGFyYW1ldGVyU3BlYyI6ImZsbHEwcUJGOFV2VXNpWHoiLCJtYXRlcmlhbFNldFNlcmlhbCI6MX0%3D&branch=master)
  [![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](https://opensource.org/licenses/MIT)
  ![Github Release](https://img.shields.io/github/release/gridsmartercities/aws-lambda-decorators.svg?style=flat)
  \
  \
  ![Python Versions](https://img.shields.io/pypi/pyversions/aws-lambda-decorators.svg?style=flat)
  ![PyPi Version](https://img.shields.io/pypi/v/aws-lambda-decorators.svg?style=flat)
  ![PyPi Status](https://img.shields.io/pypi/status/aws-lambda-decorators.svg?style=flat)
  ![Pypi Downloads](https://img.shields.io/pypi/dm/aws-lambda-decorators.svg?style=flat&logo=pypi)



  A set of Python decorators to ease the development of AWS lambda functions.



  The easiest way to use these AWS Lambda Decorators is to install them through Pip:

  `pip install aws-lambda-decorators`



  The Logging level of the decorators can be controlled by setting a LOG_LEVEL environment variable. In python:

  `os.environ["LOG_LEVEL"] = "INFO"`

  The default value is "INFO"





  The current list of AWS Lambda Python Decorators includes:

  * [__extract__](#extract): a decorator to extract and validate specific keys of a dictionary parameter passed to a AWS Lambda function.
  * [__extract_from_event__](#extract_from_event): a facade of [__extract__](#extract) to extract and validate keys from an AWS API Gateway lambda function _event_ parameter.
  * [__extract_from_context__](#extract_from_context): a facade of [__extract__](#extract) to extract and validate keys from an AWS API Gateway lambda function _context_ parameter.
  * [__extract_from_ssm__](#extract_from_ssm): a decorator to extract from AWS SSM the values of a set of parameter keys.
  * [__validate__](#validate): a decorator to validate a list of function parameters.
  * [__log__](#log): a decorator to log the parameters passed to the lambda function and/or the response of the lambda function.
  * [__handle_exceptions__](#handle_exceptions): a decorator to handle any type of declared exception generated by the lambda function.
  * [__response_body_as_json__](#response_body_as_json): a decorator to transform a response dictionary body to a json string.
  * [__handle_all_exceptions__](#handle_all_exceptions): a decorator to handle all exceptions thrown by the lambda function.
  * [__cors__](#cors): a decorator to add cors headers to a lambda function.
  * [__push_ws_errors__](#push_ws_errors): a decorator to push unsuccessful responses back to the calling user via websockets with api gateway.
  * [__push_ws_responses__](#push_ws_response): a decorator to push all responses back to the calling user via websockets with api gateway.




  Currently, the package offers 12 validators:

  * __Mandatory__: Checks if a parameter has a value.
  * __RegexValidator__: Checks a parameter against a regular expression.
  * __SchemaValidator__: Checks if an object adheres to the schema. Uses [schema](https://github.com/keleshev/schema) library.
  * __Minimum__: Checks if an optional numerical value is greater than a minimum value.
  * __Maximum__: Checks if an optional numerical value is less than a maximum value.
  * __MinLength__: Checks if an optional string value is longer than a minimum length.
  * __MaxLength__: Checks if an optional string value is shorter than a maximum length.
  * __Type__: Checks if an optional object value is of a given python type.
  * __EnumValidator__: Checks if an optional object value is in a list of valid values.
  * __NonEmpty__: Checks if an optional object value is not an empty value.
  * __DateValidator__: Checks if a given string is a valid date according to a passed in date format.
  * __CurrencyCodeValidator__: Checks if a given string is a valid currency code (ISO 4217).



  The package offers functions to decode from JSON and JWT.

  * __decode_json__: decodes/converts a json string to a python dictionary
  * __decode_jwt__: decodes/converts a JWT string to a python dictionary



  You can see some basic examples in the [examples](https://github.com/gridsmartercities/aws-lambda-decorators/blob/master/examples/examples.py) folder.



  This decorator extracts and validates values from dictionary parameters passed to a Lambda Function.

  * The decorator takes a list of __Parameter__ objects.
  * Each __Parameter__ object requires a non-empty path to the parameter in the dictionary, and the name of the dictionary (func_param_name)
  * The parameter value is extracted and added as a kwarg to the lambda handler (or any other decorated function/method).
  * You can add the parameter to the handler signature, or access it in the handler through kwargs.
  * The name of the extracted parameter is defaulted to the last element of the path name, but can be changed by passing a (valid pythonic variable name) var_name
  * You can define a default value for the parameter in the __Parameter__ or in the lambda handler itself.
  * A 400 exception is raised when the parameter cannot be extracted or when it does not validate.
  * A variable path (e.g. '/headers/Authorization[jwt]/sub') can be annotated to specify a decoding. In the example, Authorization might contain a JWT, which needs to be decoded before accessing the "sub" element.

  Example:
  ```python
  @extract(parameters=[
      Parameter(path='/parent/my_param', func_param_name='a_dictionary'),  # extracts a non mandatory my_param from a_dictionary
      Parameter(path='/parent/missing_non_mandatory', func_param_name='a_dictionary', default='I am missing'),  # extracts a non mandatory missing_non_mandatory from a_dictionary
      Parameter(path='/parent/missing_mandatory', func_param_name='a_dictionary'),  # does not fail as the parameter is not validated as mandatory
      Parameter(path='/parent/child/id', validators=[Mandatory], var_name='user_id', func_param_name='another_dictionary')  # extracts a mandatory id as "user_id" from another_dictionary
  ])
  def extract_example(a_dictionary, another_dictionary, my_param='aDefaultValue', missing_non_mandatory='I am missing', missing_mandatory=None, user_id=None):
      """
          Given these two dictionaries:

          a_dictionary = {
              'parent': {
                  'my_param': 'Hello!'
              },
              'other': 'other value'
          }

          another_dictionary = {
              'parent': {
                  'child': {
                      'id': '123'
                  }
              }
          }

          you can now access the extracted parameters directly:
      """
      return my_param, missing_non_mandatory, missing_mandatory, user_id
  ```

  Or you can use kwargs instead of specific parameter names:

  Example:
  ```python
  @extract(parameters=[
      Parameter(path='/parent/my_param', func_param_name='a_dictionary')  # extracts a non mandatory my_param from a_dictionary
  ])
  def extract_to_kwargs_example(a_dictionary, **kwargs):
      """
          a_dictionary = {
              'parent': {
                  'my_param': 'Hello!'
              },
              'other': 'other value'
          }
      """
      return kwargs['my_param']  # returns 'Hello!'
  ```

  A missing mandatory parameter, or a parameter that fails validation, will raise an exception:

  Example:
  ```python
  @extract(parameters=[
      Parameter(path='/parent/mandatory_param', func_param_name='a_dictionary', validators=[Mandatory])  # extracts a mandatory mandatory_param from a_dictionary
  ])
  def extract_mandatory_param_example(a_dictionary, mandatory_param=None):
      return 'Here!'  # this part will never be reached, if the mandatory_param is missing

  response = extract_mandatory_param_example({'parent': {'my_param': 'Hello!'}, 'other': 'other value'} )

  print(response)  # prints { 'statusCode': 400, 'body': '{"message": [{"mandatory_param": ["Missing mandatory value"]}]}' } and logs a more detailed error

  ```

  You can add custom error messages to all validators, and incorporate to those error messages the validated value and the validation condition:

  Example:
  ```python
  @extract(parameters=[
      Parameter(path='/parent/an_int', func_param_name='a_dictionary', validators=[Minimum(100, 'Bad value {value}: should be at least {condition}')])  # extracts a mandatory mandatory_param from a_dictionary
  ])
  def extract_minimum_param_with_custom_error_example(a_dictionary, mandatory_param=None):
      return 'Here!'  # this part will never be reached, if the an_int param is less than 100

  response = extract_minimum_param_with_custom_error_example({'parent': {'an_int': 10}})

  print(response)  # prints { 'statusCode': 400, 'body': '{"message": [{"an_int": ["Bad value 10: should be at least 100"]}]}' } and logs a more detailed error

  ```

  You can group the validation errors together (instead of exiting on first error).

  Example:
  ```python
  @extract(parameters=[
      Parameter(path='/parent/mandatory_param', func_param_name='a_dictionary', validators=[Mandatory]),  # extracts two mandatory parameters from a_dictionary
      Parameter(path='/parent/another_mandatory_param', func_param_name='a_dictionary', validators=[Mandatory]),
      Parameter(path='/parent/an_int', func_param_name='a_dictionary', validators=[Maximum(10), Minimum(5)])
  ], group_errors=True)  # groups both errors together
  def extract_multiple_param_example(a_dictionary, mandatory_param=None, another_mandatory_param=None, an_int=0):
      return 'Here!'  # this part will never be reached, if the mandatory_param is missing

  response = extract_multiple_param_example({'parent': {'my_param': 'Hello!', 'an_int': 20}, 'other': 'other value'})

  print(response)  # prints {'statusCode': 400, 'body': '{"message": [{"mandatory_param": ["Missing mandatory value"]}, {"another_mandatory_param": ["Missing mandatory value"]}, {"an_int": ["\'20\' is greater than maximum value \'10\'"]}]}'}

  ```

  You can decode any part of the parameter path from json or any other existing annotation.

  Example:
  ```python
  @extract(parameters=[
      Parameter(path='/parent[json]/my_param', func_param_name='a_dictionary')  # extracts a non mandatory my_param from a_dictionary
  ])
  def extract_from_json_example(a_dictionary, my_param=None):
      """
          a_dictionary = {
              'parent': '{"my_param": "Hello!" }',
              'other': 'other value'
          }
      """
      return my_param  # returns 'Hello!'

  ```

  You can also use an integer annotation to access an specific list element by index.

  Example:
  ```python
  @extract(parameters=[
      Parameter(path='/parent[1]/my_param', func_param_name='a_dictionary')  # extracts a non mandatory my_param from a_dictionary
  ])
  def extract_from_list_example(a_dictionary, my_param=None):
      """
          a_dictionary = {
              'parent': [
                  {'my_param': 'Hello!'},
                  {'my_param': 'Bye!'}
              ]
          }
      """
      return my_param  # returns 'Bye!'

  ```

  You can extract all parameters into a dictionary

  Example:
  ```python
  @extract(parameters=[
      Parameter(path='/params/my_param_1', func_param_name='a_dictionary'),  # extracts a non mandatory my_param_1 from a_dictionary
      Parameter(path='/params/my_param_2', func_param_name='a_dictionary')  # extracts a non mandatory my_param_2 from a_dictionary
  ])
  def extract_dictionary_example(a_dictionary, **kwargs):
      """
          a_dictionary = {
              'params': {
                  'my_param_1': 'Hello!',
                  'my_param_2': 'Bye!'
              }
          }
      """
      return kwargs  # returns {'my_param_1': 'Hello!', 'my_param_2': 'Bye!'}

  ```

  You can apply a transformation to an extracted value. The transformation will happen before validation.

  Example:
  ```python
  @extract(parameters=[
      Parameter(path='/params/my_param', func_param_name='a_dictionary', transform=int)  # extracts a non mandatory my_param from a_dictionary
  ])
  def extract_with_transform_example(a_dictionary, my_param=None):
      """
          a_dictionary = {
              'params': {
                  'my_param': '2'  # the original value is the string '2'
              }
          }
      """
      return my_param  # returns the int value 2

  ```

  The transform function can be any function, with its own error handling.

  Example:
  ```python

  def to_int(arg):
      try:
          return int(arg)
      except Exception:
          raise Exception("My custom error message")

  @extract(parameters=[
      Parameter(path='/params/my_param', func_param_name='a_dictionary', transform=to_int)  # extracts a non mandatory my_param from a_dictionary
  ])
  def extract_with_custom_transform_example(a_dictionary, my_param=None):
      return {}

  response = extract_with_custom_transform_example({'params': {'my_param': 'abc'}})

  print(response)  # prints {'statusCode': 400, 'body': '{"message": "Error extracting parameters"}'}, and the logs will contain the "My custom error message" message.


  ```



  This decorator is just a facade to the [extract](#extract) method to be used in AWS Api Gateway Lambdas. It automatically extracts from the event lambda parameter.

  Example:
  ```python
  @extract_from_event(parameters=[
      Parameter(path='/body[json]/my_param', validators=[Mandatory]),  # extracts a mandatory my_param from the json body of the event
      Parameter(path='/headers/Authorization[jwt]/sub', validators=[Mandatory], var_name='user_id')  # extract the mandatory sub value as user_id from the authorization JWT
  ])
  def extract_from_event_example(event, context, my_param=None, user_id=None):
      """
          event = {
              'body': '{"my_param": "Hello!"}',
              'headers': {
                  'Authorization': 'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c'
              }
          }
      """
      return my_param, user_id  # returns ('Hello!', '1234567890')
  ```



  This decorator is just a facade to the [extract](#extract) method to be used in AWS Api Gateway Lambdas. It automatically extracts from the context lambda parameter.

  Example:
  ```python
  @extract_from_context(parameters=[
      Parameter(path='/parent/my_param', validators=[Mandatory])  # extracts a mandatory my_param from the parent element in context
  ])
  def extract_from_context_example(event, context, my_param=None):
      """
          context = {
              'parent': {
                  'my_param': 'Hello!'
              }
          }
      """
      return my_param  # returns 'Hello!'
  ```



  This decorator extracts a parameter from AWS SSM and passes the parameter down to your function as a kwarg.

  * The decorator takes a list of __SSMParameter__ objects.
  * Each __SSMParameter__ object requires the name of the SSM parameter (ssm_name)
  * If no var_name is passed in, the extracted value is passed to the function with the ssm_name name

  Example:
  ```python
  @extract_from_ssm(ssm_parameters=[
      SSMParameter(ssm_name='one_key'),  # extracts the value of one_key from SSM as a kwarg named "one_key"
      SSMParameter(ssm_name='another_key', var_name="another")  # extracts another_key as a kwarg named "another"
  ])
  def extract_from_ssm_example(your_func_params, one_key=None, another=None):
      return your_func_params, one_key, another
  ```



  This decorator validates a list of non dictionary parameters from your lambda function.

  * The decorator takes a list of __ValidatedParameter__ objects.
  * Each parameter object needs the name of the lambda function parameter that it is going to be validated, and the list of rules to validate.
  * A 400 exception is raised when the parameter does not validate.

  Example:
  ```python
  @validate(parameters=[
      ValidatedParameter(func_param_name='a_param', validators=[Mandatory]),  # validates a_param as mandatory
      ValidatedParameter(func_param_name='another_param', validators=[Mandatory, RegexValidator(r'\d+')])  # validates another_param as mandatory and containing only digits
      ValidatedParameter(func_param_name='param_with_schema', validators=[SchemaValidator(Schema({'a': Or(str, dict)}))])  # validates param_with_schema as an object with specified schema
  ])
  def validate_example(a_param, another_param, param_with_schema):
      return a_param, another_param, param_with_schema  # returns 'Hello!', '123456', {'a': {'b': 'c'}}

  validate_example('Hello!', '123456', {'a': {'b': 'c'}})
  ```

  Given the same function `validate_example`, a 400 exception is returned if at least one parameter does not validate (as per the [extract](#extract) decorator, you can group errors with the group_errors flag):

  ```python
  validate_example('Hello!', 'ABCD')  # returns a 400 status code and an error message
  ```



  This decorator allows for logging the function arguments and/or the response.

  Example:
  ```python
  @log(parameters=True, response=True)
  def log_example(parameters):
      return 'Done!'

  log_example('Hello!')  # logs 'Hello!' and 'Done!'
  ```



  This decorator handles a list of exceptions, returning a 400 response containing the specified friendly message to the caller.

  * The decorator takes a list of __ExceptionHandler__ objects.
  * Each __ExceptionHandler__ requires the type of exception to check, and an optional friendly message to return to the caller.

  Example:
  ```python
  @handle_exceptions(handlers=[
      ExceptionHandler(ClientError, "Your message when a client error happens.")
  ])
  def handle_exceptions_example():
      dynamodb = boto3.resource('dynamodb')
      table = dynamodb.Table('non_existing_table')
      table.query(KeyConditionExpression=Key('user_id').eq(user_id))
      

  handle_exceptions_example()  # returns {'body': '{"message": "Your message when a client error happens."}', 'statusCode': 400}
  ```



  This decorator handles all exceptions thrown by a lambda, returning a 400 response and the exception's message.

  Example:
  ```python
  @handle_all_exceptions()
  def handle_exceptions_example():
      test_list = [1, 2, 3]
      invalid_value = test_list[5]
      

  handle_all_exceptions_example()  # returns {'body': '{"message": "list index out of range"}, 'statusCode': 400}
  ```



  This decorator ensures that, if the response contains a body, the body is dumped as json.

  * Returns a 500 error if the response body cannot be dumped as json.

  Example:
  ```python
  @response_body_as_json
  def response_body_as_json_example():
      return {'statusCode': 400, 'body': {'param': 'hello!'}}

  response_body_as_json_example()  # returns { 'statusCode': 400, 'body': "{'param': 'hello!'}" }
  ```



  This decorator adds your defined CORS headers to the decorated function response.

  * Returns a 500 error if one or more of the CORS headers have an invalid type

  Example:
  ```python
  @cors(allow_origin='*', allow_methods='POST', allow_headers='Content-Type', max_age=86400)
  def cors_example():
      return {'statusCode': 200}

  cors_example()  # returns {'statusCode': 200, 'headers': {'access-control-allow-origin': '*', 'access-control-allow-methods': 'POST', 'access-control-allow-headers': 'Content-Type', 'access-control-max-age': 86400}}
  ```



  This decorator adds HSTS header to the decorated function response. Uses 2 years max-age (recommended default from https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security) unless custom value provided as parameter.

  Example:
  ```python
  @hsts()
  def hsts_example():
      return {'statusCode': 200}

  hsts_example()  # returns {'statusCode': 200, 'headers': {'Strict-Transport-Security': 'max-age=63072000'}}
  ```



  This decorator pushes unsuccessful responses back to the calling client over websockets built on api gateway

  This decorator requires the client is connected to the websocket api gateway instance, and will therefore have a connection id

  Example:
  ```py
  @push_ws_errors('https://api_id.execute_id.region.amazonaws.com/Prod')
  @handle_all_exceptions()
  def handler(event, context):
      return {
          'statusCode': 400,
          'body': {
              'message': 'Bad request'
          }
      }


  ```



  This decorator pushes all responses back to the calling client over websockets built on api gateway

  This decorator requires the client is connected to the websocket api gateway instance, and will therefore have a connection id

  Example:
  ```py
  @push_ws_response('https://api_id.execute_id.region.amazonaws.com/Prod')
  def handler(event, context):
      return {
          'statusCode': 200,
          'body': 'Hello, world!'
      }


  ```



  You can create your own validators by inheriting from the Validator class.

  Fix length validator example:

  ```python
  class FixLength(Validator):
      ERROR_MESSAGE = "'{value}' length should be '{condition}'"

      def __init__(self, fix_length: int, error_message=None):
          super().__init__(error_message=error_message, condition=fix_length)

      def validate(self, value=None):
          if value is None:
              return True

          return len(str(value)) == self._condition
  ```



  You can get the docstring help by running:

  ```bash
  >>> from aws_lambda_decorators.decorators import extract
  >>> help(extract)
  ```



  * [PyPi](https://pypi.org/project/aws-lambda-decorators/)
  * [Test PyPi](https://test.pypi.org/project/aws-lambda-decorators/)
  * [Github](https://github.com/gridsmartercities/aws-lambda-decorators)


pkgId: 33098e69230d8ce72360bc56b20c234e34dbdc6f498826543441a5c4d5dd2e91
name: python-aws-lambda-deployment-test-utils
arch: src
version: 0.0.13
epoch: 0
release: 1
url: https://bitbucket.org/salimfadhley_ecs/aws_lambda_deployment_test_utils/src/master/
rpm_license: GPL4
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-lambda-deployment-test-utils-0.0.13-1.src.rpm
checksum_type: sha256
summary:
  A package of tools which help developers make pre and post integration tests for AWS Lambda functions.

description:
  A package of tools which help developers make pre and post integration tests for AWS Lambda functions.


pkgId: c5bcffe58950d31d5fc88cbe34f356fe3492cffc0832ab3eae87de4ea197c902
name: python-aws-lambda-env-modeler
arch: src
version: 1.0.7
epoch: 0
release: 1
url: https://github.com/ran-isenberg/aws-lambda-env-modeler
rpm_license: MIT-0
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-lambda-env-modeler-1.0.7-1.src.rpm
checksum_type: sha256
summary:
  AWS-Lambda-Env-Modeler is a Python library designed to simplify the process of managing and validating environment variables in your AWS Lambda functions.

description:
  [![license](https://img.shields.io/github/license/ran-isenberg/aws-lambda-env-modeler)](https://github.com/ran-isenberg/aws-lambda-env-modeler/blob/master/LICENSE)
  ![PythonSupport](https://img.shields.io/static/v1?label=python&message=%203.8.17|%203.9|%203.10|%203.11|%203.12&color=blue?style=flat-square&logo=python)
  ![PyPI version](https://badge.fury.io/py/aws-lambda-env-modeler.svg)
  ![PyPi monthly downloads](https://img.shields.io/pypi/dm/aws-lambda-env-modeler)
  [![codecov](https://codecov.io/gh/ran-isenberg/aws-lambda-env-modeler/branch/main/graph/badge.svg?token=P2K7K4KICF)](https://codecov.io/gh/ran-isenberg/aws-lambda-env-modeler)
  ![version](https://img.shields.io/github/v/release/ran-isenberg/aws-lambda-env-modeler)
  ![OpenSSF Scorecard](https://api.securityscorecards.dev/projects/github.com/ran-isenberg/aws-lambda-env-modeler/badge)
  ![issues](https://img.shields.io/github/issues/ran-isenberg/aws-lambda-env-modeler)

  ![alt text](https://github.com/ran-isenberg/aws-lambda-env-modeler/blob/main/docs/media/banner.png?raw=true)

  AWS-Lambda-Env-Modeler is a Python library designed to simplify the process of managing and validating environment variables in your AWS Lambda functions.

  It leverages the power of [Pydantic](https://pydantic-docs.helpmanual.io/) models to define the expected structure and types of the environment variables.

  This library is especially handy for serverless applications where managing configuration via environment variables is a common practice.

  **[📜Documentation](https://ran-isenberg.github.io/aws-lambda-env-modeler/)** | **[Blogs website](https://www.ranthebuilder.cloud)**
  > **Contact details | ran.isenberg@ranthebuilder.cloud**




  Environment variables are often viewed as an essential utility. They serve as static AWS Lambda function configuration.

  Their values are set during the Lambda deployment, and the only way to change them is to redeploy the Lambda function with updated values.

  However, many engineers use them unsafely despite being such an integral and fundamental part of any AWS Lambda function deployment.

  This usage may cause nasty bugs or even crashes in production.


  This library allows you to correctly parse, validate, and use your environment variables in your Python AWS Lambda code.

  Read more about it [here](https://www.ranthebuilder.cloud/post/aws-lambda-cookbook-environment-variables)



  - Validates the environment variables against a Pydantic model: define both semantic and syntactic validation.
  - Serializes the string environment variables into complex classes and types.
  - Provides means to access the environment variables safely with a global getter function in every part of the function.
  - Provides a decorator to initialize the environment variables before executing a function.
  - Caches the parsed model for performance improvement for multiple 'get' calls.




  You can install it using pip:

  ```bash
  pip install aws-lambda-env-modeler
  ```


  Head over to the complete project documentation pages at GitHub pages at [https://ran-isenberg.github.io/aws-lambda-env-modeler](https://ran-isenberg.github.io/aws-lambda-env-modeler/)



  First, define a Pydantic model for your environment variables:

  ```python
  from pydantic import BaseModel, HttpUrl

  class MyEnvVariables(BaseModel):
      DB_HOST: str
      DB_PORT: int
      DB_USER: str
      DB_PASS: str
      FLAG_X:  bool
      API_URL: HttpUrl
  ```

  Before executing a function, you must use the `@init_environment_variables` decorator to validate and initialize the environment variables automatically.

  The decorator guarantees that the function will run with the correct variable configuration.

  Then, you can fetch the environment variables using the global getter function, 'get_environment_variables,' and use them just like a data class. At this point, they are parsed and validated.

  ```python
  from aws_lambda_env_modeler import init_environment_variables

  @init_environment_variables(MyEnvVariables)
  def my_handler_entry_function(event, context):
      
      pass
  ```

  Then, you can fetch and validate the environment variables with your model:

  ```python
  from aws_lambda_env_modeler import get_environment_variables

  env_vars = get_environment_variables(MyEnvVariables)
  print(env_vars.DB_HOST)
  ```



  By default, the modeler uses cache - the parsed model is cached for performance improvement for multiple 'get' calls.

  In some cases, such as during testing, you may want to turn off the cache. You can do this by setting the `LAMBDA_ENV_MODELER_DISABLE_CACHE` environment variable to 'True.'

  This is especially useful in tests where you want to run multiple tests concurrently, each with a different set of environment variables.

  Here's an example of how you can use this in a pytest test:

  ```python
  import json
  from http import HTTPStatus
  from typing import Any, Dict
  from unittest.mock import patch

  from pydantic import BaseModel
  from typing_extensions import Literal

  from aws_lambda_env_modeler import LAMBDA_ENV_MODELER_DISABLE_CACHE, get_environment_variables, init_environment_variables


  class MyHandlerEnvVars(BaseModel):
      LOG_LEVEL: Literal['DEBUG', 'INFO', 'ERROR', 'CRITICAL', 'WARNING', 'EXCEPTION']


  @init_environment_variables(model=MyHandlerEnvVars)
  def my_handler(event: Dict[str, Any], context) -> Dict[str, Any]:
      env_vars = get_environment_variables(model=MyHandlerEnvVars)  # noqa: F841
      
      return {
          'statusCode': HTTPStatus.OK,
          'headers': {'Content-Type': 'application/json'},
          'body': json.dumps({'message': 'success'}),
      }


  @patch.dict('os.environ', {LAMBDA_ENV_MODELER_DISABLE_CACHE: 'true', 'LOG_LEVEL': 'DEBUG'})
  def test_my_handler():
      response = my_handler({}, None)
      assert response['statusCode'] == HTTPStatus.OK
      assert response['headers'] == {'Content-Type': 'application/json'}
      assert json.loads(response['body']) == {'message': 'success'}
  ```


  Code contributions are welcomed. Read this [guide.](https://github.com/ran-isenberg/aws-lambda-env-modeler/blob/main/CONTRIBUTING.md)


  Read our code of conduct [here.](https://github.com/ran-isenberg/aws-lambda-env-modeler/blob/main/CODE_OF_CONDUCT.md)


  * Email: [ran.isenberg@ranthebuilder.cloud](mailto:ran.isenberg@ranthebuilder.cloud)
  * Blog Website [RanTheBuilder](https://www.ranthebuilder.cloud)
  * LinkedIn: [ranisenberg](https://www.linkedin.com/in/ranisenberg/)
  * Twitter: [IsenbergRan](https://twitter.com/IsenbergRan)



  This library is licensed under the MIT License. See the [LICENSE](https://github.com/ran-isenberg/aws-lambda-env-modeler/blob/main/LICENSE) file.


pkgId: 89740aba026bf4065c8e68a71a459139372625601cbd5b265a0b7375a10f9e9a
name: python-aws-lambda-env-modeler
arch: src
version: 2.0.0
epoch: 0
release: 1
url: https://github.com/ran-isenberg/aws-lambda-env-modeler
rpm_license: MIT-0
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-lambda-env-modeler-2.0.0-1.src.rpm
checksum_type: sha256
summary:
  AWS-Lambda-Env-Modeler is a Python library designed to simplify the process of managing and validating environment variables in your AWS Lambda functions.

description:
  [![license](https://img.shields.io/github/license/ran-isenberg/aws-lambda-env-modeler)](https://github.com/ran-isenberg/aws-lambda-env-modeler/blob/master/LICENSE)
  ![PythonSupport](https://img.shields.io/static/v1?label=python&message=%203.9|%203.10|%203.11|%203.12|%203.13&color=blue?style=flat-square&logo=python)
  ![PyPI version](https://badge.fury.io/py/aws-lambda-env-modeler.svg)
  ![PyPi monthly downloads](https://img.shields.io/pypi/dm/aws-lambda-env-modeler)
  [![codecov](https://codecov.io/gh/ran-isenberg/aws-lambda-env-modeler/branch/main/graph/badge.svg?token=P2K7K4KICF)](https://codecov.io/gh/ran-isenberg/aws-lambda-env-modeler)
  ![version](https://img.shields.io/github/v/release/ran-isenberg/aws-lambda-env-modeler)
  ![OpenSSF Scorecard](https://api.securityscorecards.dev/projects/github.com/ran-isenberg/aws-lambda-env-modeler/badge)
  ![issues](https://img.shields.io/github/issues/ran-isenberg/aws-lambda-env-modeler)

  ![alt text](https://github.com/ran-isenberg/aws-lambda-env-modeler/blob/main/docs/media/banner.png?raw=true)

  AWS-Lambda-Env-Modeler is a Python library designed to simplify the process of managing and validating environment variables in your AWS Lambda functions.

  It leverages the power of [Pydantic](https://pydantic-docs.helpmanual.io/) models to define the expected structure and types of the environment variables.

  This library is especially handy for serverless applications where managing configuration via environment variables is a common practice.

  **[📜Documentation](https://ran-isenberg.github.io/aws-lambda-env-modeler/)** | **[Blogs website](https://www.ranthebuilder.cloud)**
  > **Contact details | ran.isenberg@ranthebuilder.cloud**




  Environment variables are often viewed as an essential utility. They serve as static AWS Lambda function configuration.

  Their values are set during the Lambda deployment, and the only way to change them is to redeploy the Lambda function with updated values.

  However, many engineers use them unsafely despite being such an integral and fundamental part of any AWS Lambda function deployment.

  This usage may cause nasty bugs or even crashes in production.


  This library allows you to correctly parse, validate, and use your environment variables in your Python AWS Lambda code.

  Read more about it [here](https://www.ranthebuilder.cloud/post/aws-lambda-cookbook-environment-variables)



  - Validates the environment variables against a Pydantic model: define both semantic and syntactic validation.
  - Serializes the string environment variables into complex classes and types.
  - Provides means to access the environment variables safely with a global getter function in every part of the function.
  - Provides a decorator to initialize the environment variables before executing a function.
  - Caches the parsed model for performance improvement for multiple 'get' calls.




  You can install it using pip:

  ```bash
  pip install aws-lambda-env-modeler
  ```


  Head over to the complete project documentation pages at GitHub pages at [https://ran-isenberg.github.io/aws-lambda-env-modeler](https://ran-isenberg.github.io/aws-lambda-env-modeler/)



  First, define a Pydantic model for your environment variables:

  ```python
  from pydantic import BaseModel, HttpUrl

  class MyEnvVariables(BaseModel):
      DB_HOST: str
      DB_PORT: int
      DB_USER: str
      DB_PASS: str
      FLAG_X:  bool
      API_URL: HttpUrl
  ```

  Before executing a function, you must use the `@init_environment_variables` decorator to validate and initialize the environment variables automatically.

  The decorator guarantees that the function will run with the correct variable configuration.

  Then, you can fetch the environment variables using the global getter function, 'get_environment_variables,' and use them just like a data class. At this point, they are parsed and validated.

  ```python
  from aws_lambda_env_modeler import init_environment_variables

  @init_environment_variables(MyEnvVariables)
  def my_handler_entry_function(event, context):
      
      pass
  ```

  Then, you can fetch and validate the environment variables with your model:

  ```python
  from aws_lambda_env_modeler import get_environment_variables

  env_vars = get_environment_variables(MyEnvVariables)
  print(env_vars.DB_HOST)
  ```



  By default, the modeler uses cache - the parsed model is cached for performance improvement for multiple 'get' calls.

  In some cases, such as during testing, you may want to turn off the cache. You can do this by setting the `LAMBDA_ENV_MODELER_DISABLE_CACHE` environment variable to 'True.'

  This is especially useful in tests where you want to run multiple tests concurrently, each with a different set of environment variables.

  Here's an example of how you can use this in a pytest test:

  ```python
  import json
  from http import HTTPStatus
  from typing import Any, Dict
  from unittest.mock import patch

  from pydantic import BaseModel
  from typing_extensions import Literal

  from aws_lambda_env_modeler import LAMBDA_ENV_MODELER_DISABLE_CACHE, get_environment_variables, init_environment_variables


  class MyHandlerEnvVars(BaseModel):
      LOG_LEVEL: Literal['DEBUG', 'INFO', 'ERROR', 'CRITICAL', 'WARNING', 'EXCEPTION']


  @init_environment_variables(model=MyHandlerEnvVars)
  def my_handler(event: Dict[str, Any], context) -> Dict[str, Any]:
      env_vars = get_environment_variables(model=MyHandlerEnvVars)  # noqa: F841
      
      return {
          'statusCode': HTTPStatus.OK,
          'headers': {'Content-Type': 'application/json'},
          'body': json.dumps({'message': 'success'}),
      }


  @patch.dict('os.environ', {LAMBDA_ENV_MODELER_DISABLE_CACHE: 'true', 'LOG_LEVEL': 'DEBUG'})
  def test_my_handler():
      response = my_handler({}, None)
      assert response['statusCode'] == HTTPStatus.OK
      assert response['headers'] == {'Content-Type': 'application/json'}
      assert json.loads(response['body']) == {'message': 'success'}
  ```


  Code contributions are welcomed. Read this [guide.](https://github.com/ran-isenberg/aws-lambda-env-modeler/blob/main/CONTRIBUTING.md)


  Read our code of conduct [here.](https://github.com/ran-isenberg/aws-lambda-env-modeler/blob/main/CODE_OF_CONDUCT.md)


  * Email: [ran.isenberg@ranthebuilder.cloud](mailto:ran.isenberg@ranthebuilder.cloud)
  * Blog Website [RanTheBuilder](https://www.ranthebuilder.cloud)
  * LinkedIn: [ranisenberg](https://www.linkedin.com/in/ranisenberg/)
  * Twitter: [RanBuilder](https://twitter.com/RanBuilder)



  This library is licensed under the MIT License. See the [LICENSE](https://github.com/ran-isenberg/aws-lambda-env-modeler/blob/main/LICENSE) file.


pkgId: ee655bc8b0ca3ac2624108a3d332e671b2f0ac2e428764257ef6f37e1f54a7b6
name: python-aws-lambda-invoker
arch: src
version: 0.0.1
epoch: 0
release: 1
summary: AWS Lambda invoker
url: https://github.com/SirPaulO/aws_lambda_invoker
rpm_license: MIT License
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-lambda-invoker-0.0.1-1.src.rpm
checksum_type: sha256
description:
  Simple package for lambda invocation with AWS boto3.
  This package is intended to be used as an interface for invoking AWS Lambda functions emulating AWS API Gateway, SNS, Event bridge and SQS.



  ```console
  $ pip install aws-lambda-invoker
  ```




  ```python
  invoker = LambdaInvoker(
      lambda_name="TEST-LAMBDA",
      payload="{\"key\": \"value\"}",
      invoke_type=InvokeType.RequestResponse,
  )
  response = invoker.invoke()



  invoker = AGLambdaInvoker(
      lambda_name="TEST-LAMBDA",
      method="GET",
      path="TEST-path",
      body="TEST-body",
      headers={"key": "value"},
      query_params={"key": "value"},
      path_params={"key": "value"},
  )
  response = invoker.invoke()
  ```


pkgId: 0302758ef2fa9117d4b0f95efdadff9faa812134741c08db59ec6213f6aaf7fe
name: python-aws-lambda-powertools
arch: src
version: 2.43.1
epoch: 0
release: 1
url: https://github.com/aws-powertools/powertools-lambda-python
rpm_license: MIT
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-lambda-powertools-2.43.1-1.src.rpm
checksum_type: sha256
summary:
  Powertools for AWS Lambda (Python) is a developer toolkit to implement Serverless best practices and increase developer velocity.

description:
  <!-- markdownlint-disable MD013 MD041 MD043  -->


  [![Build](https://github.com/aws-powertools/powertools-lambda-python/actions/workflows/quality_check.yml/badge.svg)](https://github.com/aws-powertools/powertools-lambda-python/actions/workflows/python_build.yml)
  [![codecov.io](https://codecov.io/github/aws-powertools/powertools-lambda-python/branch/develop/graphs/badge.svg)](https://app.codecov.io/gh/aws-powertools/powertools-lambda-python)
  ![PythonSupport](https://img.shields.io/static/v1?label=python&message=%203.8|%203.9|%203.10|%203.11|%203.12&color=blue?style=flat-square&logo=python) ![PyPI version](https://badge.fury.io/py/aws-lambda-powertools.svg) ![PyPi monthly downloads](https://img.shields.io/pypi/dm/aws-lambda-powertools) [![OpenSSF Scorecard](https://api.securityscorecards.dev/projects/github.com/aws-powertools/powertools-lambda-python/badge)](https://api.securityscorecards.dev/projects/github.com/aws-powertools/powertools-lambda-python) [![Join our Discord](https://dcbadge.vercel.app/api/server/B8zZKbbyET?style=flat-square)](https://discord.gg/B8zZKbbyET)

  Powertools for AWS Lambda (Python) is a developer toolkit to implement Serverless [best practices and increase developer velocity](https://docs.powertools.aws.dev/lambda/python/latest/#features).

  > Also available in [Java](https://github.com/aws-powertools/powertools-lambda-java), [Typescript](https://github.com/aws-powertools/powertools-lambda-typescript), and [.NET](https://github.com/aws-powertools/powertools-lambda-dotnet).

  **[📜Documentation](https://docs.powertools.aws.dev/lambda/python/)** | **[🐍PyPi](https://pypi.org/project/aws-lambda-powertools/)** | **[Roadmap](https://docs.powertools.aws.dev/lambda/python/latest/roadmap/)** | **[Detailed blog post](https://aws.amazon.com/blogs/opensource/simplifying-serverless-best-practices-with-lambda-powertools/)**

  ![hero-image](https://user-images.githubusercontent.com/3340292/198254617-d0fdb672-86a6-4988-8a40-adf437135e0a.png)



  * **[Tracing](https://docs.powertools.aws.dev/lambda/python/latest/core/tracer/)** - Decorators and utilities to trace Lambda function handlers, and both synchronous and asynchronous functions
  * **[Logging](https://docs.powertools.aws.dev/lambda/python/latest/core/logger/)** - Structured logging made easier, and decorator to enrich structured logging with key Lambda context details
  * **[Metrics](https://docs.powertools.aws.dev/lambda/python/latest/core/metrics/)** - Custom Metrics created asynchronously via CloudWatch Embedded Metric Format (EMF)
  * **[Event handler: AppSync](https://docs.powertools.aws.dev/lambda/python/latest/core/event_handler/appsync/)** - AWS AppSync event handler for Lambda Direct Resolver and Amplify GraphQL Transformer function
  * **[Event handler: API Gateway and ALB](https://docs.powertools.aws.dev/lambda/python/latest/core/event_handler/api_gateway/)** - Amazon API Gateway REST/HTTP API and ALB event handler for Lambda functions invoked using Proxy integration
  * **[Event handler: Agents for Amazon Bedrock](https://docs.powertools.aws.dev/lambda/python/latest/core/event_handler/bedrock_agents/)** - Create Agents for Amazon Bedrock, automatically generating OpenAPI schemas
  * **[Bring your own middleware](https://docs.powertools.aws.dev/lambda/python/latest/utilities/middleware_factory/)** - Decorator factory to create your own middleware to run logic before, and after each Lambda invocation
  * **[Parameters utility](https://docs.powertools.aws.dev/lambda/python/latest/utilities/parameters/)** - Retrieve and cache parameter values from Parameter Store, Secrets Manager, or DynamoDB
  * **[Batch processing](https://docs.powertools.aws.dev/lambda/python/latest/utilities/batch/)** - Handle partial failures for AWS SQS batch processing
  * **[Typing](https://docs.powertools.aws.dev/lambda/python/latest/utilities/typing/)** - Static typing classes to speedup development in your IDE
  * **[Validation](https://docs.powertools.aws.dev/lambda/python/latest/utilities/validation/)** - JSON Schema validator for inbound events and responses
  * **[Event source data classes](https://docs.powertools.aws.dev/lambda/python/latest/utilities/data_classes/)** - Data classes describing the schema of common Lambda event triggers
  * **[Parser](https://docs.powertools.aws.dev/lambda/python/latest/utilities/parser/)** - Data parsing and deep validation using Pydantic
  * **[Idempotency](https://docs.powertools.aws.dev/lambda/python/latest/utilities/idempotency/)** - Convert your Lambda functions into idempotent operations which are safe to retry
  * **[Data Masking](https://docs.powertools.aws.dev/lambda/python/latest/utilities/data_masking/)** -  Protect confidential data with easy removal or encryption
  * **[Feature Flags](https://docs.powertools.aws.dev/lambda/python/latest/utilities/feature_flags/)** - A simple rule engine to evaluate when one or multiple features should be enabled depending on the input
  * **[Streaming](https://docs.powertools.aws.dev/lambda/python/latest/utilities/streaming/)** - Streams datasets larger than the available memory as streaming data.



  With [pip](https://pip.pypa.io/en/latest/index.html) installed, run: ``pip install aws-lambda-powertools``



  * [Tutorial](https://docs.powertools.aws.dev/lambda/python/latest/tutorial)
  * [Serverless Shopping cart](https://github.com/aws-samples/aws-serverless-shopping-cart)
  * [Serverless Airline](https://github.com/aws-samples/aws-serverless-airline-booking)
  * [Serverless E-commerce platform](https://github.com/aws-samples/aws-serverless-ecommerce-platform)
  * [Serverless GraphQL Nanny Booking Api](https://github.com/trey-rosius/babysitter_api)





  Knowing which companies are using this library is important to help prioritize the project internally. If your company is using Powertools for AWS Lambda (Python), you can request to have your name and logo added to the README file by raising a [Support Powertools for AWS Lambda (Python) (become a reference)](https://github.com/aws-powertools/powertools-lambda-python/issues/new?assignees=&labels=customer-reference&template=support_powertools.yml&title=%5BSupport+Lambda+Powertools%5D%3A+%3Cyour+organization+name%3E) issue.

  The following companies, among others, use Powertools:

  * [Alma Media](https://www.almamedia.fi/en/)
  * [Banxware](https://www.banxware.com/)
  * [Brsk](https://www.brsk.co.uk/)
  * [BusPatrol](https://buspatrol.com/)
  * [Capital One](https://www.capitalone.com/)
  * [Caylent](https://caylent.com/)
  * [CHS Inc.](https://www.chsinc.com/)
  * [CPQi (Exadel Financial Services)](https://cpqi.com/)
  * [CloudZero](https://www.cloudzero.com/)
  * [CyberArk](https://www.cyberark.com/)
  * [globaldatanet](https://globaldatanet.com/)
  * [IMS](https://ims.tech/)
  * [Jit Security](https://www.jit.io/)
  * [LocalStack](https://www.localstack.cloud/)
  * [Propellor.ai](https://www.propellor.ai/)
  * [Recast](https://getrecast.com/)
  * [TopSport](https://www.topsport.com.au/)
  * [Transformity](https://transformity.tech/)
  * [Trek10](https://www.trek10.com/)
  * [Vertex Pharmaceuticals](https://www.vrtx.com/)



  Share what you did with Powertools for AWS Lambda (Python) 💞💞. Blog post, workshops, presentation, sample apps and others. Check out what the community has already shared about Powertools for AWS Lambda (Python) [here](https://docs.powertools.aws.dev/lambda/python/latest/we_made_this/).



  This helps us understand who uses Powertools for AWS Lambda (Python) in a non-intrusive way, and helps us gain future investments for other Powertools for AWS Lambda languages. When [using Layers](https://docs.powertools.aws.dev/lambda/python/latest/#lambda-layer), you can add Powertools for AWS Lambda (Python) as a dev dependency (or as part of your virtual env) to not impact the development process.



  * Structured logging initial implementation from [aws-lambda-logging](https://gitlab.com/hadrien/aws_lambda_logging)
  * Powertools for AWS Lambda (Python) idea [DAZN Powertools](https://github.com/getndazn/dazn-lambda-powertools/)



  * **Powertools for AWS Lambda on Discord**: `#python` - **[Invite link](https://discord.gg/B8zZKbbyET)**
  * **Email**: <aws-powertools-maintainers@amazon.com>



  If you think you’ve found a potential security issue, please do not post it in the Issues.  Instead, please follow the instructions [here](https://aws.amazon.com/security/vulnerability-reporting/) or [email AWS security directly](mailto:aws-security@amazon.com).



  This library is licensed under the MIT-0 License. See the LICENSE file.


pkgId: a326cb5942bdbdb2de047403ffc51806c9e1cd3f099f63b5bce222686eb3afb7
name: python-aws-lambda-powertools
arch: src
version: 3.1.0
epoch: 0
release: 1
url: https://github.com/aws-powertools/powertools-lambda-python
rpm_license: MIT
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-lambda-powertools-3.1.0-1.src.rpm
checksum_type: sha256
summary:
  Powertools for AWS Lambda (Python) is a developer toolkit to implement Serverless best practices and increase developer velocity.

description:
  <!-- markdownlint-disable MD013 MD041 MD043  -->


  [![Build](https://github.com/aws-powertools/powertools-lambda-python/actions/workflows/quality_check.yml/badge.svg)](https://github.com/aws-powertools/powertools-lambda-python/actions/workflows/python_build.yml)
  [![codecov.io](https://codecov.io/github/aws-powertools/powertools-lambda-python/branch/develop/graphs/badge.svg)](https://app.codecov.io/gh/aws-powertools/powertools-lambda-python)
  ![PythonSupport](https://img.shields.io/static/v1?label=python&message=%203.8|%203.9|%203.10|%203.11|%203.12&color=blue?style=flat-square&logo=python) ![PyPI version](https://badge.fury.io/py/aws-lambda-powertools.svg) ![PyPi monthly downloads](https://img.shields.io/pypi/dm/aws-lambda-powertools) [![OpenSSF Scorecard](https://api.securityscorecards.dev/projects/github.com/aws-powertools/powertools-lambda-python/badge)](https://api.securityscorecards.dev/projects/github.com/aws-powertools/powertools-lambda-python) [![Join our Discord](https://dcbadge.vercel.app/api/server/B8zZKbbyET?style=flat-square)](https://discord.gg/B8zZKbbyET)

  Powertools for AWS Lambda (Python) is a developer toolkit to implement Serverless [best practices and increase developer velocity](https://docs.powertools.aws.dev/lambda/python/latest/#features).

  > Also available in [Java](https://github.com/aws-powertools/powertools-lambda-java), [Typescript](https://github.com/aws-powertools/powertools-lambda-typescript), and [.NET](https://github.com/aws-powertools/powertools-lambda-dotnet).

  **[📜Documentation](https://docs.powertools.aws.dev/lambda/python/)** | **[🐍PyPi](https://pypi.org/project/aws-lambda-powertools/)** | **[Roadmap](https://docs.powertools.aws.dev/lambda/python/latest/roadmap/)** | **[Detailed blog post](https://aws.amazon.com/blogs/opensource/simplifying-serverless-best-practices-with-lambda-powertools/)**

  ![hero-image](https://user-images.githubusercontent.com/3340292/198254617-d0fdb672-86a6-4988-8a40-adf437135e0a.png)



  * **[Tracing](https://docs.powertools.aws.dev/lambda/python/latest/core/tracer/)** - Decorators and utilities to trace Lambda function handlers, and both synchronous and asynchronous functions
  * **[Logging](https://docs.powertools.aws.dev/lambda/python/latest/core/logger/)** - Structured logging made easier, and decorator to enrich structured logging with key Lambda context details
  * **[Metrics](https://docs.powertools.aws.dev/lambda/python/latest/core/metrics/)** - Custom Metrics created asynchronously via CloudWatch Embedded Metric Format (EMF)
  * **[Event handler: AppSync](https://docs.powertools.aws.dev/lambda/python/latest/core/event_handler/appsync/)** - AWS AppSync event handler for Lambda Direct Resolver and Amplify GraphQL Transformer function
  * **[Event handler: API Gateway and ALB](https://docs.powertools.aws.dev/lambda/python/latest/core/event_handler/api_gateway/)** - Amazon API Gateway REST/HTTP API and ALB event handler for Lambda functions invoked using Proxy integration
  * **[Event handler: Agents for Amazon Bedrock](https://docs.powertools.aws.dev/lambda/python/latest/core/event_handler/bedrock_agents/)** - Create Agents for Amazon Bedrock, automatically generating OpenAPI schemas
  * **[Bring your own middleware](https://docs.powertools.aws.dev/lambda/python/latest/utilities/middleware_factory/)** - Decorator factory to create your own middleware to run logic before, and after each Lambda invocation
  * **[Parameters utility](https://docs.powertools.aws.dev/lambda/python/latest/utilities/parameters/)** - Retrieve and cache parameter values from Parameter Store, Secrets Manager, or DynamoDB
  * **[Batch processing](https://docs.powertools.aws.dev/lambda/python/latest/utilities/batch/)** - Handle partial failures for AWS SQS batch processing
  * **[Typing](https://docs.powertools.aws.dev/lambda/python/latest/utilities/typing/)** - Static typing classes to speedup development in your IDE
  * **[Validation](https://docs.powertools.aws.dev/lambda/python/latest/utilities/validation/)** - JSON Schema validator for inbound events and responses
  * **[Event source data classes](https://docs.powertools.aws.dev/lambda/python/latest/utilities/data_classes/)** - Data classes describing the schema of common Lambda event triggers
  * **[Parser](https://docs.powertools.aws.dev/lambda/python/latest/utilities/parser/)** - Data parsing and deep validation using Pydantic
  * **[Idempotency](https://docs.powertools.aws.dev/lambda/python/latest/utilities/idempotency/)** - Convert your Lambda functions into idempotent operations which are safe to retry
  * **[Data Masking](https://docs.powertools.aws.dev/lambda/python/latest/utilities/data_masking/)** -  Protect confidential data with easy removal or encryption
  * **[Feature Flags](https://docs.powertools.aws.dev/lambda/python/latest/utilities/feature_flags/)** - A simple rule engine to evaluate when one or multiple features should be enabled depending on the input
  * **[Streaming](https://docs.powertools.aws.dev/lambda/python/latest/utilities/streaming/)** - Streams datasets larger than the available memory as streaming data.



  With [pip](https://pip.pypa.io/en/latest/index.html) installed, run: ``pip install aws-lambda-powertools``



  * [Tutorial](https://docs.powertools.aws.dev/lambda/python/latest/tutorial)
  * [Serverless Shopping cart](https://github.com/aws-samples/aws-serverless-shopping-cart)
  * [Serverless Airline](https://github.com/aws-samples/aws-serverless-airline-booking)
  * [Serverless E-commerce platform](https://github.com/aws-samples/aws-serverless-ecommerce-platform)
  * [Serverless GraphQL Nanny Booking Api](https://github.com/trey-rosius/babysitter_api)





  Knowing which companies are using this library is important to help prioritize the project internally. If your company is using Powertools for AWS Lambda (Python), you can request to have your name and logo added to the README file by raising a [Support Powertools for AWS Lambda (Python) (become a reference)](https://github.com/aws-powertools/powertools-lambda-python/issues/new?assignees=&labels=customer-reference&template=support_powertools.yml&title=%5BSupport+Lambda+Powertools%5D%3A+%3Cyour+organization+name%3E) issue.

  The following companies, among others, use Powertools:

  * [Alma Media](https://www.almamedia.fi/en/)
  * [Banxware](https://www.banxware.com/)
  * [Brsk](https://www.brsk.co.uk/)
  * [BusPatrol](https://buspatrol.com/)
  * [Capital One](https://www.capitalone.com/)
  * [Caylent](https://caylent.com/)
  * [CHS Inc.](https://www.chsinc.com/)
  * [CPQi (Exadel Financial Services)](https://cpqi.com/)
  * [CloudZero](https://www.cloudzero.com/)
  * [CyberArk](https://www.cyberark.com/)
  * [Flyweight](https://flyweight.io/)
  * [globaldatanet](https://globaldatanet.com/)
  * [IMS](https://ims.tech/)
  * [Jit Security](https://www.jit.io/)
  * [LocalStack](https://www.localstack.cloud/)
  * [Propellor.ai](https://www.propellor.ai/)
  * [Pushpay](https://pushpay.com/)
  * [Recast](https://getrecast.com/)
  * [TopSport](https://www.topsport.com.au/)
  * [Transformity](https://transformity.tech/)
  * [Trek10](https://www.trek10.com/)
  * [Vertex Pharmaceuticals](https://www.vrtx.com/)



  Share what you did with Powertools for AWS Lambda (Python) 💞💞. Blog post, workshops, presentation, sample apps and others. Check out what the community has already shared about Powertools for AWS Lambda (Python) [here](https://docs.powertools.aws.dev/lambda/python/latest/we_made_this/).



  This helps us understand who uses Powertools for AWS Lambda (Python) in a non-intrusive way, and helps us gain future investments for other Powertools for AWS Lambda languages. When [using Layers](https://docs.powertools.aws.dev/lambda/python/latest/#lambda-layer), you can add Powertools for AWS Lambda (Python) as a dev dependency (or as part of your virtual env) to not impact the development process.



  * Structured logging initial implementation from [aws-lambda-logging](https://gitlab.com/hadrien/aws_lambda_logging)
  * Powertools for AWS Lambda (Python) idea [DAZN Powertools](https://github.com/getndazn/dazn-lambda-powertools/)



  * **Powertools for AWS Lambda on Discord**: `#python` - **[Invite link](https://discord.gg/B8zZKbbyET)**
  * **Email**: <aws-powertools-maintainers@amazon.com>



  If you think you’ve found a potential security issue, please do not post it in the Issues.  Instead, please follow the instructions [here](https://aws.amazon.com/security/vulnerability-reporting/) or [email AWS security directly](mailto:aws-security@amazon.com).



  This library is licensed under the MIT-0 License. See the LICENSE file.


pkgId: 596a93c07c878884d10a987c134283493dd744a6070648399e6e46481b9ef0b4
name: python-aws-lambda-publish-shared-event
arch: src
version: 0.20.0
epoch: 0
release: 1
summary: Cli to publish shareable Lambda test events.
url: https://lambda.101i.de/
rpm_license: MIT
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-lambda-publish-shared-event-0.20.0-1.src.rpm
checksum_type: sha256
description:
  [![Build status](https://github.com/michaelbrewer/aws-lambda-events/actions/workflows/python.yml/badge.svg)](https://github.com/michaelbrewer/aws-lambda-events/actions/workflows/python.yml)
  [![Code Coverage](https://codecov.io/gh/michaelbrewer/aws-lambda-events/branch/main/graph/badge.svg?token=J433NUHYNT)](https://codecov.io/gh/michaelbrewer/aws-lambda-events)
  [![Package version](https://img.shields.io/pypi/v/aws-lambda-publish-shared-event?color=%2334D058&label=pypi%20package)](https://pypi.org/project/aws-lambda-publish-shared-event/)
  ![Python version](https://img.shields.io/pypi/pyversions/aws-lambda-publish-shared-event.svg?color=%2334D058)



  - Publish your locally defined test events to the Lambda Console (`publish-shared-event -e testEvent.json ..`)
  - Publish 100 different examples (`publish-shared-event -e ses/ses.json ...`)
  - Publish multiple events with the same schema structure for a single Lambda
  - Set test name or use the test event file name (`publish-shared-event -n custom-name ...`)
  - Get the list of built-in test events (`publish-shared-event --list`)
  - Geneate a new test event (`generate-test-event ses/ses.json > event.json`)



  Recommended to install via pipx: `pipx install aws-lambda-publish-shared-event`, see the [pipx installation guide](https://pypa.github.io/pipx/installation/) for more.

  Alternatively pip installed, run: `pip install aws-lambda-publish-shared-event`



  Once installed run `publish-shared-event --help` for the list of commands.

  Listing supported events for cognito user pool:

  ```script
  $ publish-shared-event --filtered-list cognito-user
  Filtered list of supported event sources:
  cognito-user-pool/create-auth-challenge.json
  cognito-user-pool/custom-email-sender.json
  cognito-user-pool/custom-message.json
  cognito-user-pool/define-auth-challenge.json
  cognito-user-pool/post-authentication.json
  cognito-user-pool/post-confirmation.json
  cognito-user-pool/pre-authentication.json
  cognito-user-pool/pre-signup.json
  cognito-user-pool/pre-token-generation.json
  cognito-user-pool/user-migration.json
  cognito-user-pool/verify-auth-challenge-response.json
  ```

  Publishing a `ses/ses.json` test event as a shareable event for the Lambda function named `full-lambda-name`

  ```script
  publish-shared-event -e ses/ses.json -f full-lambda-name -r us-east-1
  ```

  Publishes a locally defined test event `events/yourOwnDefinedEvent.json` to the Lambda console

  ```script
  publish-shared-event -e events/yourOwnDefinedEvent.json -f your-function -r us-west-2
  ```

  Publish two different tests with custom names.

  > **NOTE:** Both tests must share the same schema

  ```script
  publish-shared-event -n createCustomerPass -e eventOne.json -f full-lambda-name -r us-east-1
  publish-shared-event -n createCustomerFailure -e eventTwo.json -f full-lambda-name -r us-east-1
  ```

  Using the interactive cli tool:

  ```script
  $ publish-shared-event
  Lambda Name: <Full Lambda Name>
  Select Event:
  * alb/alb.json
      alexa/alex-smart-home-skill-v1.json
      alexa/alex-smart-home-skill-v3.json
      amazon-config/amazon-config.json
      ...
  ```

  Generate new local test event:

  ```script
  generate-test-event ses/ses.json > event.json
  ```



  See [Lambda Events](https://lambda.101i.de/) for more documentation on the different AWS Lambda event structures
  and see the official docs on [AWS Lambda Shareable test events](https://docs.aws.amazon.com/lambda/latest/dg/testing-functions.html#creating-shareable-events).





  - Bump dep pick to 2.2.0



  - Bump deps



  - Bump deps
  - Version command



  - Bump deps for pick to 1.4.0



  - Bump deps for pick to 1.3.0



  - Add `--filtered-list` argument to `generate-test-event`



  - Add `alexa-skills-kit` sample events



  - Fix packaging to include `generate_test_event`



  - Add `generate-test-event` support
  - Add python 3.7 support



  - Add support for python 3.8



  - Add python 3.10 and dependabot
  - Add security and linting
  - Add coverage report



  - Add long form cli arguments (`--region`, `--lambda-name`, `--event-name`)



  - Update dependencies and clean up code


pkgId: a544566b3e3272ea0b62638d5b9fa4dd672fe6197442fb137e1b28349c38a3f6
name: python-aws-lambda-typing
arch: src
version: 2.20.0
epoch: 0
release: 1
summary: A package that provides type hints for AWS Lambda event, context and response objects
url: https://github.com/MousaZeidBaker/aws-lambda-typing
rpm_license: MIT
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-lambda-typing-2.20.0-1.src.rpm
checksum_type: sha256
description:
  ![build](https://github.com/MousaZeidBaker/aws-lambda-typing/workflows/Publish/badge.svg)
  ![test](https://github.com/MousaZeidBaker/aws-lambda-typing/workflows/Test/badge.svg)
  [![License](https://img.shields.io/badge/License-MIT-yellow)](LICENSE)
  ![python_version](https://img.shields.io/badge/python-%3E=3.6-blue.svg)
  [![pypi_v](https://img.shields.io/pypi/v/aws-lambda-typing)](https://pypi.org/project/aws-lambda-typing)
  [![pypi_dm](https://img.shields.io/pypi/dm/aws-lambda-typing)](https://pypi.org/project/aws-lambda-typing)

  A package that provides type hints for AWS Lambda event, context and response
  objects. It's a convenient way to get autocomplete and type hints built into
  IDEs. Type annotations are not checked at runtime but are only enforced by third
  party tools such as type checkers, IDEs, linters, etc.


  - [Usage](#usage)
  - [Demo](#demo)
  - [Types](#types)
    - [Context](#context)
    - [Events](#events)
    - [Responses](#responses)
  - [Test](#test)
  - [Contributing](#contributing)
  - [Issues](#issues)




  ```python
  from aws_lambda_typing import context as context_, events


  def handler(event: events.SQSEvent, context: context_.Context) -> None:
      for record in event['Records']:
          print(record['body'])

      print(context.get_remaining_time_in_millis())

      message: events.sqs.SQSMessage

  ```



  ![ide_autocomplete](https://raw.githubusercontent.com/MousaZeidBaker/aws-lambda-typing/master/media/ide_autocomplete.gif)


  ![code_reference_information](https://raw.githubusercontent.com/MousaZeidBaker/aws-lambda-typing/master/media/code_reference_information.gif)



  - Context


  - ALBEvent
  - ApacheKafkaEvent
  - APIGatewayRequestAuthorizerEvent
  - APIGatewayTokenAuthorizerEvent
  - APIGatewayProxyEventV1
  - APIGatewayProxyEventV2
  - AppSyncResolverEvent
  - CloudFormationCustomResourceEvent
  - CloudWatchEventsMessageEvent (Deprecated since version 2.10.0: use `EventBridgeEvent` instead.)
  - CloudWatchLogsEvent
  - CodeCommitMessageEvent
  - CodePipelineEvent
  - CognitoCustomMessageEvent
  - CognitoPostConfirmationEvent
  - ConfigEvent
  - DynamoDBStreamEvent
  - EventBridgeEvent
  - EC2ASGCustomTerminationPolicyEvent
  - IoTPreProvisioningHookEvent
  - KinesisFirehoseEvent
  - KinesisStreamEvent
  - MQEvent
  - MSKEvent
  - S3Event
  - S3BatchEvent
  - SecretsManagerRotationEvent
  - SESEvent
  - SNSEvent
  - SQSEvent
  - WebSocketConnectEvent
  - WebSocketRouteEvent


  - SNSPublish
  - SNSPublishBatch


  - ALBResponse
  - APIGatewayAuthorizerResponse
  - APIGatewayProxyResponseV1
  - APIGatewayProxyResponseV2
  - DynamoDBBatchResponse
  - IoTPreProvisioningHookResponse
  - KinesisFirehoseTransformationResponse
  - S3BatchResponse


  - PolicyDocument



  Contributions are welcome! See the [Contributing Guide](https://github.com/MousaZeidBaker/aws-lambda-typing/blob/master/CONTRIBUTING.md).



  If you encounter any problems, please file an
  [issue](https://github.com/MousaZeidBaker/aws-lambda-typing/issues) along with a
  detailed description.


pkgId: 700bc0a89eb345f25a7221886cb575b41b8f1ce33fa81d47cc11cb01dd12679e
name: python-aws-list-all
arch: src
version: 0.9.2
epoch: 0
release: 1
summary: List all your AWS resources, all regions, all services.
url: https://github.com/JohannesEbke/aws_list_all
rpm_license: MIT License
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-list-all-0.9.2-1.src.rpm
checksum_type: sha256
description:
  List all resources in an AWS account, all regions, all services(*). Writes JSON files for further processing.
  (*) No guarantees for completeness. Use billing alerts if you are worried about costs.
  (Note that the build will break on some boto3 updates)


pkgId: e174a7f6a707437afa3f0846ee581f5622858851432a9e51a4387ef0b7c46320
name: python-aws-logging-handlers
arch: src
version: 2.0.5
epoch: 0
release: 1
url: https://github.com/omrikiei/aws_logging_handlers/
rpm_license: MIT License
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-logging-handlers-2.0.5-1.src.rpm
checksum_type: sha256
summary:
  Logging aws_logging_handlers to AWS services that support S3 and Kinesis stream logging with multiple threads

description:
  A python multithreaded logging handler package that streams records to
  AWS services objects with support for the following AWS services: \* S3
  \* Kinesis
  Supports gzip compression(in S3)


pkgId: 2c750caee69b73aa1f03af50b18ce1a40998c1d9c36718d9fc8efbd8a88923d7
name: python-aws-login
arch: src
version: 0.1.4
epoch: 0
release: 1
summary: AWS login using the Secure Token Service
url: https://github.com/binxio/aws-login
rpm_license: UNKNOWN
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-login-0.1.4-1.src.rpm
checksum_type: sha256
description:
  A simple command line utility to login to AWS accounts using role based access and the secure token service.


  **Options**

  Usage: aws_login [OPTIONS] ACTION

    Aws-login is an AWS Helper CLI for using Role Based Access, easy and
    securly open the management console with the command line.

    Actions:

    aws-login start-mfa-session, aws-login mfa

    aws-login add-profile, aws-login add

    aws-login open-console, aws-login oc

    aws-login print-console, aws-login pc

  Options:
    -s, --source-profile TEXT       The source profile.
    -t, --target-profile TEXT       The target profile.
    -r, --role TEXT                 The role to assume
    -a, --account-id TEXT           Account ID to assume the role
    -v, --verbose                   show verbose output.
    -p, --profile TEXT              Use this profile for mfa session or opening
                                    console.
    -E, --mfa-expiration INTEGER    number of seconds after which the MFA
                                    credentials are no longer valid
    -R, --role-expiration INTEGER   number of seconds after which the role
                                    credentials are no longer valid
    -C, --console-expiration INTEGER
                                    number of seconds after which the console
                                    credentials are no longer valid
    -T, --token TEXT                from your MFA device
    -h, --help                      Show this message and exit.

  **Example**


pkgId: 2c7d4c4e060174c5c5086a2f7e812e7b1d2cac3f77769021b85bb6bf71eb3ac8
name: python-aws-mfa
arch: src
version: 0.0.12
epoch: 0
release: 1
summary: Manage AWS MFA Security Credentials
url: https://github.com/broamski/aws-mfa
rpm_license: MIT
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-mfa-0.0.12-1.src.rpm
checksum_type: sha256
description:
  **aws-mfa** makes it easy to manage your AWS SDK Security Credentials when Multi-Factor Authentication (MFA) is enforced on your AWS account. It automates the process of obtaining temporary credentials from the [AWS Security Token Service](http://docs.aws.amazon.com/STS/latest/APIReference/Welcome.html) and updating your [AWS Credentials](https://blogs.aws.amazon.com/security/post/Tx3D6U6WSFGOK2H/A-New-and-Standardized-Way-to-Manage-Credentials-in-the-AWS-SDKs) file (located at `~/.aws/credentials`). Traditional methods of managing MFA-based credentials requires users to write their own bespoke scripts/wrappers to fetch temporary credentials from STS and often times manually update their AWS credentials file.
  The concept behind **aws-mfa** is that there are 2 types of credentials:
  * `long-term` - Your typcial AWS access keys, consisting of an `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY`
  * `short-term` - A temporary set of credentials that are generated by AWS STS using your `long-term` credentials in combination with your MFA device serial number (either a hardware device serial number or virtual device ARN) and one time token code. Your short term credentials are the credentials that are actively utilized by the AWS SDK in use.
  If you haven't yet enabled multi-factor authentication for AWS API access, check out the [AWS article](http://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) on doing so.


pkgId: 79e129664f9f45acf17c2243d4455d645761272dcd3f18d3c2e32ae3c862ae1e
name: python-aws-mlops
arch: src
version: 1.2.2
epoch: 0
release: 1
summary: AWS MLOps Python package
url: https://aws-mlops.readthedocs.io/
rpm_license: MIT License
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-mlops-1.2.2-1.src.rpm
checksum_type: sha256
description:
  AWS MLOps package is implemented to help you like a framework for deploying what it is necessary to manage your models.
  The goal is to implement this package to keep your focus on your prep and test code using the AWS SageMaker services, AWS Step Functions and AWS Lambda.
  It is part of the `educational repositories <https://github.com/pandle/materials>`_ to learn how to write stardard code and common uses of the TDD and CI / CD.
  Prerequisites

  You can use `Serverless framework <https://www.serverless.com/framework/docs/providers/aws/guide/installation/>`_ for deploying the AWS services:
  if you want to use the guide below, you have to install `npm <https://www.npmjs.com/get-npm>`_ (`Node Package Manager <https://docs.npmjs.com/cli/v6/commands>`_) before.
  If you want to use another AWS tool, you can see the repository `aws-tool-comparison <https://github.com/bilardi/aws-tool-comparison>`_ before to implement your version.
  Installation

  The package is not self-consistent. So you have to download the package by github and to install the requirements before to deploy the **example** on AWS:
      git clone https://github.com/bilardi/aws-mlops
      cd aws-mlops/
      npm install
      export AWS_PROFILE=your-account
      export STAGE=studio
      bash example/deploy.sh
  Or if you want to use this package into your code, you can install by python3-pip:
      pip3 install aws_mlops
      python3
      >>> import aws_mlops
      >>> help(aws_mlops)
  Read the documentation on `readthedocs <https://aws-mlops.readthedocs.io/en/latest/>`_ for
  * Usage
  * Development
  Change Log

  See `CHANGELOG.md <https://github.com/bilardi/aws-mlops/blob/master/CHANGELOG.md>`_ for details.
  License

  This package is released under the MIT license.  See `LICENSE <https://github.com/bilardi/aws-mlops/blob/master/LICENSE>`_ for details.


pkgId: 8db0f903bfb55274802caa6b05072e00bff0b57b88c9dc5764ba6a79eb51903b
name: python-aws-monocyte
arch: src
version: 0.3.509.post312
epoch: 0
release: 1
summary: Monocyte - Search and Destroy unwanted AWS Resources relentlessly.
url: https://github.com/ImmobilienScout24/aws-monocyte
rpm_license: Apache License 2.0
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-monocyte-0.3.509.post312-1.src.rpm
checksum_type: sha256
description:
  Monocyte is a bot for destroying AWS resources in non-EU regions written in Python using Boto.
      It is especially useful for companies that are bound to European privacy laws
      and for that reason don't want to process user data in non-EU regions.


pkgId: 9bac8f82a1c7ede1fd91257c57c3eef8893f847cc0e3d2c19fc67644ca6014c8
name: python-aws-nuke-exporter
arch: src
version: 1.0.4
epoch: 0
release: 1
summary: A tool for exporting aws-nuke logs in JSON or CSV formats.
url: https://github.com/oijkn/aws-nuke-exporter
rpm_license: GPL
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-nuke-exporter-1.0.4-1.src.rpm
checksum_type: sha256
description:
  If you find this repository useful, please consider giving it a star. Your support is greatly appreciated! :pray:


  AWS Nuke Exporter is a Python tool designed to parse and export the output logs of the [aws-nuke](https://github.com/rebuy-de/aws-nuke) command into more structured and readable formats: JSON or CSV. This tool simplifies the process of analyzing and storing the results generated by AWS Nuke, making it easier for users to review and track the resources managed by AWS Nuke.


  - **Multiple Output Formats**: Supports exporting data into JSON or CSV formats.
  - **Detailed Parsing**: Extracts detailed information from the AWS Nuke logs, including resource types, IDs, regions, and additional details.
  - **Customizable Export Paths**: Allows users to specify custom paths for the exported data.


  - Python 3
  - AWS CLI (for `aws-nuke` command execution)





  You can install `aws-nuke-exporter` directly from PyPI:

  ```bash
  pip install aws-nuke-exporter
  ```

  This command will install the latest version of the `aws-nuke-exporter` package along with all necessary dependencies.



  Alternatively, you can clone the repository and install it manually:

  ```bash
  git clone https://github.com/oijkn/aws-nuke-exporter.git
  cd aws-nuke-exporter
  python setup.py install
  ```



  After installation, you can use `aws-nuke-exporter` from the command line:

  ```bash
  aws-nuke-exporter <path-to-aws-nuke-output> -f <format> -d <destination-path>
  ```

  Or alternatively, build and use the Docker image. To build the image:
  ```bash
  docker build -t aws-nuke-exporter .
  ```
  To use the docker image run it as follows:

  ```bash
  docker run docker run --rm -v $PWD/:/data <image_name> /data/<aws-nuke-output_file> -d /data/<exported_file>
  ```



  - `path-to-aws-nuke-output`: The file path where AWS Nuke output is stored.
  - `-f, --format [json|csv]`: The output format. Choose between JSON and CSV (default: JSON).
  - `-d, --destination`: The path where the exported file will be saved (optional).
  - `-q, --quiet`: Run in quiet mode, no logs will be printed to stdout (default: False).
  - `-v, --version`: Prints the version of the tool.



  Export AWS Nuke output to JSON:

  ```bash
  aws-nuke-exporter output.log -f json
  ```

  Export AWS Nuke output to CSV with a custom destination:

  ```bash
  aws-nuke-exporter output.log -f csv -d /path/to/export.csv
  ```

  Run the docker image, passing in the current directory and exporting as JSON to a file named 'export.json':
  ```bash
  docker run --rm -v $PWD/:/data nuke-export /data/aws-nuke-output.txt -d /data/export.json
  ```


  Contributions to the AWS Nuke Exporter are welcome. Please ensure that your code adheres to the existing style and that all tests pass.


  This project is licensed under the [GNU General Public License (GPL)](LICENSE).


  For any questions or feedback, please open an issue on GitHub.


pkgId: 31e18c82372a744061f8c7bcc56383c70ffe7097467fdd3960b2730c17373e14
name: python-aws-parallelcluster-node
arch: src
version: 3.11.1
epoch: 0
release: 1
summary: aws-parallelcluster-node provides the scripts for an AWS ParallelCluster node.
url: https://github.com/aws/aws-parallelcluster-node
rpm_license: Apache License 2.0
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-parallelcluster-node-3.11.1-1.src.rpm
checksum_type: sha256
description:
  aws-parallelcluster-node is the python package installed on the Amazon EC2 instances launched as part of AWS ParallelCluster.


pkgId: 543ece1f7b0a10cc32162bfe075832ccfd89e2056e5affe23415d25a93c43c43
name: python-aws-pdk
arch: src
version: 0.25.0
epoch: 0
release: 1
summary: @aws/pdk
url: https://github.com/aws/aws-pdk
rpm_license: Apache-2.0
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-pdk-0.25.0-1.src.rpm
checksum_type: sha256
description:
  All documentation is located at: https://aws.github.io/aws-pdk



  Please refer to [Developer Guide](./docs/developer_guides/aws-arch/index.md).



  Please refer to [Developer Guide](./docs/developer_guides/cdk-graph/index.md).



  Please refer to [Developer Guide](./docs/developer_guides/cdk-graph-plugin-diagram/index.md).



  Please refer to [Developer Guide](./docs/developer_guides/cdk-graph-plugin-threat-composer/index.md).



  Please refer to [Developer Guide](./docs/developer_guides/cloudscape-react-ts-website/index.md).



  Please refer to [Developer Guide](./docs/developer_guides/identity/index.md).



  Please refer to [Developer Guide](./docs/developer_guides/infrastructure/index.md).



  Please refer to [Developer Guide](./docs/developer_guides/monorepo/index.md).



  Please refer to [Developer Guide](./docs/developer_guides/pdk-nag/index.md).



  Please refer to [Developer Guide](./docs/developer_guides/pipeline/index.md).



  Please refer to [Developer Guide](./docs/developer_guides/static-website/index.md).



  Please refer to [Developer Guide](./docs/developer_guides/type-safe-api/index.md).


pkgId: b7670ca5fdffe10222bd3392bc326a37a75dc1eee88412e9abd7a535eabff18a
name: python-aws-prototyping-sdk
arch: src
version: 0.17.5
epoch: 0
release: 1
summary: aws-prototyping-sdk
url: https://github.com/aws/aws-prototyping-sdk
rpm_license: Apache-2.0
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-prototyping-sdk-0.17.5-1.src.rpm
checksum_type: sha256
description:
  > **DEPRECATION NOTICE:** The `aws-prototyping-sdk` is on path to deprecation. This package is simply a wrapper around the individual `@aws-prototyping-skd/*` packages and has no unique code aside from bundling the other packages. Due to lack of significant value compared to maintenance overhead, this package will be deprecated soon in favor of using the individual packages directly. Please use the individual packages starting now to prevent future migration and loss of update capabilities.

  The aws-prototyping-sdk provides stable CDK and Projen constructs, allowing developers to have access to higher level abstractions than provided by the CDK or Projen alone.

  For detailed documentation, please refer to the [documentation website](https://aws.github.io/aws-prototyping-sdk/).



  This package simply bundles various packages from the `@aws-prototyping-sdk` namespace which have been marked as `stable`. As such, not all constructs or classes may be exported from this package and will need to be explicitly imported by creating a dependency on the individual packages.

  To illustrate, at the time of writing the following individual packages are published:

  ```
  @aws-prototyping-sdk
          |_ pipeline       : [stable]
          |_ nx-monorepo    : [stable]
          |_ static-website : [experimental]
          |_ identity       : [experimental]
  ```

  The aws-prototyping-sdk package will bundle all stable packages and export them as namespaces as follows:

  ```
  aws-prototyping-sdk
          |_ pipeline
          |_ nx_monorepo
  ```

  This means if you wanted to access the PDKPipeline which is a stable construct, you simply add a dependency on the `aws-prototyping-sdk` and import it as follows:

  ```python
  import { nx_monorepo, pipeline } from "aws-prototyping-sdk";
  ```

  To import `experimental` constructs, a dependency on the individual package is required. In the case of `static-website`, a dependency on `@aws-prototyping-sdk/static-website` is required. The constructs can then be imported as follows:

  ```python
  import { StaticWebsite } from "@aws-prototyping-sdk/static-website";
  ```


pkgId: d7f1c3dcf1d9f32d6ce12bc22101041a9d6e67c7927fa4658331d343d118f88c
name: python-aws-prototyping-sdk.aws-arch
arch: src
version: 0.19.68
epoch: 0
release: 1
summary: @aws-prototyping-sdk/aws-arch
url: https://github.com/aws/aws-prototyping-sdk
rpm_license: Apache-2.0
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-prototyping-sdk.aws-arch-0.19.68-1.src.rpm
checksum_type: sha256
description:
  Library to provide metadata for AWS Services and AWS Resources.

  This package generates mappings between [@aws-cdk/cfnspec](https://github.com/aws/aws-cdk/blob/main/packages/%40aws-cdk/cfnspec) and [AWS Architecture Icons](https://aws.amazon.com/architecture/icons/), and resolves resource metadata between these systems to infer a normalized definition of an `AwsService` and `AwsResource`.

  The primary aim of this package is to provide a consistent mechanism for other libraries to retrieve naming and assets associated with CloudFormation resources, and by extension CDK resources.



  ```sh
  yarn add '@aws-prototyping-sdk/aws-arch'
  ```

  ```python
  import { AwsArchitecture } from "@aws-prototyping-sdk/aws-arch";

  const s3Bucket = AwsArchitecture.getResource("AWS::S3::Bucket");
  const s3Service = AwsArchitecture.getService(s3Bucket.service);

  console.log(s3Bucket);
  console.log(s3Service);
  ```

  ```js
  // => console.log(s3Bucket);
  {
  	"name": "Amazon Simple Storage Service Bucket",
  	"cfnType": "AWS::S3::Bucket",
  	"awsAssetName": "Amazon-Simple-Storage-Service_Bucket",
  	"awsAssetIcon": "resources/Amazon-Simple-Storage-Service_Bucket.png",
  	"service": "S3"
  }

  // => console.log(s3Service);
  {
  	"provider": "AWS",
  	"name": "Amazon Simple Storage Service",
  	"cfnName": "S3",
  	"awsAssetIcon": "services/Amazon-Simple-Storage-Service.png",
  	"awsAssetName": "Amazon-Simple-Storage-Service"
  }
  ```



  Retrieve **category**, **service**, and **resource** [AWS Architecture Icons](https://aws.amazon.com/architecture/icons/).

  > Icon methods return relative asset key paths, as most frameworks have the concept of a base path (imagepaths). Use `AwsArchitecture.resolveAssetPath(...)` to get absolute path.



  **Resource Icon**

  ```python
  const s3Bucket = AwsArchitecture.getResource("AWS::S3::Bucket");

  const s3BucketPng = s3Bucket.icon("png"); // => "storage/s3/bucket.png"
  const s3BucketSvg = s3Bucket.icon("svg"); // => "storage/s3/bucket.svg"

  // Resolve absolute path for icons
  AwsArchitecture.resolveAssetPath(s3BucketPng); // => /User/example/.../node_modules/@aws-prototyping-sdk/aws-arc/assets/storage/s3/bucket.png
  ```

  **Service Icon**

  ```python
  const s3Service = AwsArchitecture.getResource("AWS::S3::Bucket").service;
  // equivalent to: `AwsArchitecture.getService("S3")`

  const s3ServicePng = s3Service.icon("png"); // => "storage/s3/service_icon.png"
  const s3ServiceSvg = s3Service.icon("svg"); // => "storage/s3/service_icon.svg"

  // Resolve absolute path for icons
  AwsArchitecture.resolveAssetPath(s3ServicePng); // => /User/example/.../node_modules/@aws-prototyping-sdk/aws-arc/assets/storage/s3/service_icon.png
  ```

  **Category Icon**

  ```python
  const storageCategory =
    AwsArchitecture.getResource("AWS::S3::Bucket").service.category;
  // equivalent to: `AwsArchitecture.getCategory("storage")`

  const storageCategoryPng = storageCategory.icon("png"); // => "storage/category_icon.png"
  const storageCategorySvg = storageCategory.icon("svg"); // => "storage/category_icon.svg"

  // Resolve absolute path for icons
  AwsArchitecture.resolveAssetPath(storageCategoryPng); // => /User/example/.../node_modules/@aws-prototyping-sdk/aws-arc/assets/storage/category_icon.png
  ```



  This package auto-generates many types and asset files from external sources,
  which are then auto mapped based on common patterns and explict mappings for edge-cases.

  The auto-generation is handled by `/scripts` files which can be run via corresponding
  package scripts (eg: `npx projen generate:assets` => `/scripts/generate-assets.ts`).

  There is an implicit sequential order the scripts must be called in due to dependencies,
  which is handled by `npx projen generate` script. The `generate` script is also invoked
  prior to `npx projen build` if generated asset directory does not exist.

  For local development of packages that depend on `aws-arch` package, you will need to
  call `npx projen generate && npx projen compile` (or `npx projen build`) prior to locally
  importing this package.

  To update [AWS Architecture Icons](https://aws.amazon.com/architecture/icons/), change the url in [ASSET_PACKAGE_ZIP_URL](packages/aws-arch/scripts/generate-assets.ts).


pkgId: 66d0fce26217a010eb140d3209927e79b43f2874db44a22d457a5399f3bd0a45
name: python-aws-prototyping-sdk.awsui-react-ts-website
arch: src
version: 0.3.14
epoch: 0
release: 1
summary: @aws-prototyping-sdk/awsui-react-ts-website
url: https://github.com/aws/aws-prototyping-sdk
rpm_license: Apache-2.0
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-prototyping-sdk.awsui-react-ts-website-0.3.14-1.src.rpm
checksum_type: sha256
description:
  To create a new [AWS UI](https://github.com/aws/awsui-documentation) React Typescript Project, there are a couple of options:



  ```
  npx projen new --from @aws-prototyping-sdk/awsui-react-ts-website awsui-react-ts-website [--application-name <your-app>]
  ```



  ```python
  new AwsUiReactTsWebsiteProject({
      defaultReleaseBranch: "mainline",
      name: "<name-of-package>",
      applicationName: "<name-of-app>",
  });
  ```



  To run your synthesized application locally, run `npx projen dev`.



  To enable Cognito auth, ensure you have a runtime-config.json file in the root of your deployed project which at least contains the following:

  ```json
  {
      "region": "<aws-region>",
      "identityPoolId":"<identity-pool-id>",
      "userPoolId":"<user-pool-id>",
      "userPoolWebClientId":"<user-pool-web-client-id>"
  }
  ```

  The easiest way to get this set up is to use the static-website + identity packages to deploy your website.

  An example of how to do this is as follows:

  ```python
  const userIdentity = new UserIdentity(this, 'UserIdentity');
  new StaticWebsite(this, 'StaticWebsite', {
      websiteContentPath: '<relative>/<path>/<to>/<built>/<website>',
      runtimeOptions: {
          jsonPayload: {
              region: Stack.of(this).region,
              identityPoolId: userIdentity.identityPool.identityPoolId,
              userPoolId: userIdentity.userPool?.userPoolId,
              userPoolWebClientId: userIdentity.userPoolClient?.userPoolClientId,
          }
      },
  });
  ```

  For local development, you will need to copy the generated runtime-config.json file into your /public directory. An example on how to do this is as follows:

  ```
  curl https://dxxxxxxxxxx.cloudfront.net/runtime-config.json > public/runtime-config.json
  ```


pkgId: c75b72b93ac627f171fd65a570658fa966199b878ee10927f7b820705609fdda
name: python-aws-prototyping-sdk.nx-monorepo
arch: src
version: 0.19.68
epoch: 0
release: 1
summary: @aws-prototyping-sdk/nx-monorepo
url: https://github.com/aws/aws-prototyping-sdk
rpm_license: Apache-2.0
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-prototyping-sdk.nx-monorepo-0.19.68-1.src.rpm
checksum_type: sha256
description:
  The nx-monorepo package vends a NxMonorepoProject Projen construct that adds [NX](https://nx.dev/getting-started/intro) monorepo support and manages your yarn/npm/pnpm workspaces on your behalf. This construct enables polyglot builds (and inter language build dependencies), build caching, dependency visualization and much, much more.

  The PDK itself uses the nx-monorepo project itself and is a good reference for seeing how a complex, polyglot monorepo can be set up.

  > **BREAKING CHANGES** (pre-release)
  >
  > * v0.13.0: `WorkspaceConfig.nxConfig` type `NxConfig => Nx.WorkspaceConfig`, and `overrideProjectTargets` removed in favor of `PDKProject.nx` config to manage Nx project configurations. See [PR 231](https://github.com/aws/aws-prototyping-sdk/pull/231).

  To get started simply run the following command in an empty directory:

  ```bash
  npx projen new --from @aws-prototyping-sdk/nx-monorepo
  ```

  This will bootstrap a new Projen monorepo and contain the following in the .projenrc.ts:

  ```python
  import { nx_monorepo } from "aws-prototyping-sdk";

  const project = new nx_monorepo.NxMonorepoProject({
    defaultReleaseBranch: "main",
    deps: ["aws-cdk-lib", "constructs", "cdk-nag"],
    devDeps: ["aws-prototyping-sdk"],
    name: "my-package",
  });

  project.synth();
  ```

  To add new packages to the monorepo, you can simply add them as a child to the monorepo. To demonstrate, lets add a PDK Pipeline TS Project as a child as follows:

  ```python
  import { nx_monorepo } from "aws-prototyping-sdk";

  const project = new nx_monorepo.NxMonorepoProject({
    defaultReleaseBranch: "main",
    deps: ["aws-cdk-lib", "constructs", "cdk-nag"],
    devDeps: ["aws-prototyping-sdk"],
    name: "my-package",
  });

  new PDKPipelineTsProject({
    parent: project,
    outdir: "packages/cicd",
    defaultReleaseBranch: "mainline",
    name: "cicd",
    cdkVersion: "2.1.0"
  });

  project.synth();
  ```

  Once added, run `npx projen` from the root directory. You will now notice a new TS package has been created under the packages/cicd path.

  Now let's add a python project to the monorepo and add an inter-language build dependency.

  ```python
  import { nx_monorepo } from "aws-prototyping-sdk";
  import { PDKPipelineTsProject } from "aws-prototyping-sdk/pipeline";
  import { PythonProject } from "projen/lib/python";

  const project = new nx_monorepo.NxMonorepoProject({
    defaultReleaseBranch: "main",
    deps: ["aws-cdk-lib", "constructs", "cdk-nag"],
    devDeps: ["aws-prototyping-sdk"],
    name: "test",
  });

  const pipelineProject = new PDKPipelineTsProject({
    parent: project,
    outdir: "packages/cicd",
    defaultReleaseBranch: "mainline",
    name: "cicd",
    cdkVersion: "2.1.0"
  });

  // Standard Projen projects also work here
  const pythonlib = new PythonProject({
    parent: project,
    outdir: "packages/pythonlib",
    authorEmail: "",
    authorName: "",
    moduleName: "pythonlib",
    name: "pythonlib",
    version: "0.0.0"
  });

  // Pipeline project depends on pythonlib to build first
  project.addImplicitDependency(pipelineProject, pythonlib);

  project.synth();
  ```

  Run `npx projen` from the root directory. You will now notice a new Python package has been created under packages/pythonlib.

  To visualize our dependency graph, run the following command from the root directory: `npx nx graph`.

  Now lets test building our project, from the root directory run `npx nx run-many --target=build --nx-bail`. As you can see, the pythonlib was built first followed by the cicd package.

  > This is equivalent to running `yarn build`, `pnpm build`, or `npm run build` depending on your node package manager, and similarly `yarn build` also accepts the same [Nx Run-Many options](https://nx.dev/packages/nx/documents/run-many#options) (eg: `yarn build --projects=cicd`).

  The NxMonorepoProject also manages your yarn/pnpm workspaces for you and synthesizes these into your package.json pnpm-workspace.yml respectively.

  For more information on NX commands, refer to this [documentation](https://nx.dev/using-nx/nx-cli).



  As well as adding implicit dependencies, you can add dependencies between projects of the same language in order to have one project consume another project's code.



  Since the `NxMonorepoProject` manages a yarn/npm/pnpm workspace, configuring dependencies between Typescript projects is as straightforward as referencing them in `deps`.

  Note that dependencies cannot be added in the same project synthesis (`npx projen`) as when projects are created. This means a two-pass approach is recommended, first to create your new projects, and then to add the dependencies.

  For example:

  First add your new projects:

  ```python
  new TypeScriptProject({
    parent: monorepo,
    outdir: "packages/a",
    defaultReleaseBranch: "main",
    name: "project-a"
  });

  new TypeScriptProject({
    parent: monorepo,
    outdir: "packages/b",
    defaultReleaseBranch: "main",
    name: "project-b",
  });
  ```

  Synthesise, then you can set up your dependency:

  ```python
  const a = new TypeScriptProject({
    parent: monorepo,
    outdir: "packages/a",
    defaultReleaseBranch: "main",
    name: "project-a"
  });

  new TypeScriptProject({
    parent: monorepo,
    outdir: "packages/b",
    defaultReleaseBranch: "main",
    name: "project-b",
    // B depends on A
    deps: [a.package.packageName],
  });
  ```





  The recommended way to configure dependencies between python projects within your monorepo is to use Poetry. Poetry sets up separate virtual environments per project but also supports local file dependencies. You can use the monorepo's `addPythonPoetryDependency` method:

  ```python
  const a = new PythonProject({
    parent: monorepo,
    outdir: 'packages/a',
    moduleName: 'a',
    name: 'a',
    authorName: 'jack',
    authorEmail: 'me@example.com',
    version: '1.0.0',
    poetry: true,
  });

  const b = new PythonProject({
    parent: monorepo,
    outdir: 'packages/b',
    moduleName: 'b',
    name: 'b',
    authorName: 'jack',
    authorEmail: 'me@example.com',
    version: '1.0.0',
    poetry: true,
  });

  // b depends on a
  monorepo.addPythonPoetryDependency(b, a);
  ```



  If you are using pip for your python projects, you can set up a dependency using a single shared virtual environment. You can then install packages you wish to depend on into that environment using pip's [Editable Installs](https://pip.pypa.io/en/stable/topics/local-project-installs/#editable-installs).

  You will also need to add an implicit dependency to tell the monorepo the correct build order for your packages.

  For example:

  ```python
  const sharedEnv: VenvOptions = {
    envdir: '../../.env',
  };

  const a = new PythonProject({
    parent: monorepo,
    outdir: 'packages/a',
    moduleName: 'a',
    name: 'a',
    authorName: 'jack',
    authorEmail: 'me@example.com',
    version: '1.0.0',
    venvOptions: sharedEnv,
  });

  // Install A into the virtual env since it is consumed by B
  a.tasks.tryFind('install')!.exec('pip install --editable .');

  const b = new PythonProject({
    parent: monorepo,
    outdir: 'packages/b',
    moduleName: 'b',
    name: 'b',
    authorName: 'jack',
    authorEmail: 'me@example.com',
    version: '1.0.0',
    venvOptions: sharedEnv,
    // B depends on A
    deps: [a.moduleName],
  });

  // Add the implicit dependency so that the monorepo will build A before B
  monorepo.addImplicitDependency(b, a);
  ```



  The recommended way to configure dependencies between java projects within your monorepo is to use shared maven repositories. The default java project build will already create a distributable in the correct format for a maven repository in its `dist/java` folder, so you can use this as a repository. You can use the monorepo's `addJavaDependency` method:

  For example:

  ```python
  const a = new JavaProject({
    parent: monorepo,
    outdir: 'packages/a',
    groupId: 'com.mycompany',
    artifactId: 'a',
    name: 'a',
    version: '1.0.0',
  });

  const b = new JavaProject({
    parent: monorepo,
    outdir: 'packages/b',
    groupId: 'com.mycompany',
    artifactId: 'b',
    name: 'b',
    version: '1.0.0',
  });

  // b depends on a
  monorepo.addJavaDependency(b, a);
  ```


pkgId: 0942f98883343bcb1ea02a242e05dfd652861c746402c8820450cb0443961e10
name: python-aws-prototyping-sdk.pdk-nag
arch: src
version: 0.19.68
epoch: 0
release: 1
summary: @aws-prototyping-sdk/pdk-nag
url: https://github.com/aws/aws-prototyping-sdk
rpm_license: Apache-2.0
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-prototyping-sdk.pdk-nag-0.19.68-1.src.rpm
checksum_type: sha256
description:
  PDKNag ships with a helper utility that automatically configures CDKNag within your application.

  ```python
  const app = PDKNag.app();
  const stack = new Stack(app, 'MyStack');
  ...
  ```

  As shown above, this will configure your application to have CDKNag run on synthesis.

  By default, CDK will trigger a failure on `synth` if any errors are encountered. To relax these, run the following:

  ```shell
  cdk synth --ignore-errors
  ```

  Conversely, CDK will not fail on synth if warnings are detected. To enforce that all warnings are resolved, run the following command:

  ```shell
  cdk synth --strict
  ```



  By default, when creating a PDKNag application the [AwsSolutions](https://github.com/cdklabs/cdk-nag/blob/main/RULES.md) NagPack is instrumented. In order to specify custom NagPacks to instrument, you can configure the PDKApp as follows:

  ```python
  import { PDKNag, AwsPrototypingChecks } from "@aws-prototyping-sdk/pdk-nag";

  const app = PDKNag.app({
      nagPacks: [new AwsPrototypingChecks()]
  });
  ```

  In this example, the [AwsPrototypingChecks](https://github.com/aws/aws-prototyping-sdk/blob/mainline/packages/pdk-nag/src/packs/README.md) NagPack has been configured to run instead of the default. Multiple NagPacks can also be instrumented by adding NagPack instances to the `nagPacks` array;


pkgId: 5f1b54b2e7e204665e544611d35e25c0093e4aec3be11baa97f8465f64399a45
name: python-aws-quota-checker
arch: src
version: 1.12.0
epoch: 0
release: 1
summary: A CLI tool that checks your AWS quota utilization
url: https://pypi.org/project/aws-quota-checker/
rpm_license: UNKNOWN
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-quota-checker-1.12.0-1.src.rpm
checksum_type: sha256
description:
  A tool that helps keeping track of your AWS quota utilization. It'll determine the limits of your AWS account and compare them to the number of current resources.

  ![Example output of aws-quota-checker](https://raw.githubusercontent.com/brennerm/aws-quota-checker/master/img/example.png)

  This is especially useful cause today, cloud resources are being created from all kinds of sources, e.g. IaC and Kubernetes operators. This tool will give you a head start for requesting quota increases before you hit a quota limit to prevent being stuck with a production system not being able to scale anymore.

  A usual use case is to add it to your CI pipeline right after applying your IaC or run it on a regular basis. It also comes with a Prometheus exporter mode that allows you to visualize the data with your tool of choice, e.g. Grafana.

  ![Example Grafana dashboard that uses metrics of the Prometheus exporter](https://raw.githubusercontent.com/brennerm/aws-quota-checker/master/img/example-grafana-dashboard.png)





  ```bash
  pip install aws-quota-checker
  ```



  ```bash
  docker run -e AWS_ACCESS_KEY_ID=ABC -e AWS_SECRET_ACCESS_KEY=DEF -e AWS_DEFAULT_REGION=eu-central-1 ghcr.io/brennerm/aws-quota-checker
  ```

  or

  ```bash
  aws configure
  docker run -v ~/.aws/credentials:/home/aqc/.aws/credentials:ro ghcr.io/brennerm/aws-quota-checker
  ```



  ```bash
  git clone git@github.com:brennerm/aws-quota-checker.git
  cd aws-quota-checker
  pip install .
  ```



  Make sure you are logged into your AWS account (`aws configure` or through environment variables) or switch to the one you want to check. This account needs to have read permissions for all supported services. AWS provides a default policy called _ReadOnlyAccess_ that contains the required permissions.

  Check the help page with `aws-quota-checker --help` to see all available command and their documentation.



  ```bash
  $ aws-quota-checker check vpc_count
  AWS profile: default | AWS region: eu-central-1 | Active checks: vpc_count
  VPCs per Region [default/eu-central-1]: 1/5 ✓
  ```



  ```bash
  $ aws-quota-checker check all
  AWS profile: default | AWS region: eu-central-1 | Active checks: route53_traffic_policy_count,vpc_count,ec2_tgw_count,ec2_on_demand_standard_count,route53_health_check_count,cw_alarm_count,iam_attached_policy_per_role,asg_count,elasticbeanstalk_environment_count,s3_bucket_count,iam_attached_policy_per_user,elb_listeners_per_alb,ec2_eip_count,route53resolver_rule_count,iam_policy_version_count,elb_listeners_per_nlb,vpc_subnets_per_vpc,route53_vpcs_per_hosted_zone,cf_stack_count,iam_user_count,elb_listeners_per_clb,ni_count,dyndb_table_count,elasticbeanstalk_application_count,route53_traffic_policy_instance_count,ig_count,elb_clb_count,ec2_vpn_connection_count,route53_reusable_delegation_set_count,ebs_snapshot_count,route53_hosted_zone_count,iam_attached_policy_per_group,eks_count,am_mesh_count,elb_target_group_count,route53resolver_rule_association_count,iam_server_certificate_count,elb_alb_count,vpc_acls_per_vpc,iam_group_count,ec2_spot_standard_count,route53resolver_endpoint_count,iam_policy_count,elb_nlb_count,sg_count,route53_records_per_hosted_zone,lc_count,ecs_count,secretsmanager_secrets_count
  Collecting checks  [####################################]  100%
  Route53 Traffic Policies per Account [default]: 0/50 ✓
  VPCs per Region [default/eu-central-1]: 1/5 ✓
  Transit Gateways per Account [default]: 4/5 !
  Running On-Demand Standard (A, C, D, H, I, M, R, T, Z) EC2 instances [default]: 0/1280 ✓
  Route53 Health Checks per Account [default]: 0/200 ✓
  Number of CloudWatch alarms per Region [default/eu-central-1]: 0/5000 ✓
  Auto Scaling groups per Region [default/eu-central-1]: 0/200 ✓
  Elastic Beanstalk Environments per Account [default]: 0/200 ✓
  Application Load Balancers per Region [default/eu-central-1]: 46/50 X
  ...
  ```



  ```bash
  $ aws-quota-checker check-instance vpc_acls_per_vpc vpc-0123456789
  Network ACLs per VPC [default/eu-central-1/vpc-0123456789]: 0/200
  ```



  The Prometheus exporter requires additional dependencies that you need to install with `pip install aws-quota-checker[prometheus]`.

  ```bash
  $ aws-quota-checker prometheus-exporter all
  AWS profile: default | AWS region: us-east-1 | Active checks: am_mesh_count,asg_count,cf_stack_count,cw_alarm_count,dyndb_table_count,ebs_snapshot_count,ec2_eip_count,ec2_on_demand_f_count,ec2_on_demand_g_count,ec2_on_demand_inf_count,ec2_on_demand_p_count,ec2_on_demand_standard_count,ec2_on_demand_x_count,ec2_spot_f_count,ec2_spot_g_count,ec2_spot_inf_count,ec2_spot_p_count,ec2_spot_standard_count,ec2_spot_x_count,ec2_tgw_count,ec2_vpn_connection_count,ecs_count,eks_count,elasticbeanstalk_application_count,elasticbeanstalk_environment_count,elb_alb_count,elb_clb_count,elb_listeners_per_alb,elb_listeners_per_clb,elb_listeners_per_nlb,elb_nlb_count,elb_target_group_count,iam_attached_policy_per_group,iam_attached_policy_per_role,iam_attached_policy_per_user,iam_group_count,iam_policy_count,iam_policy_version_count,iam_server_certificate_count,iam_user_count,ig_count,lc_count,ni_count,route53_health_check_count,route53_hosted_zone_count,route53_records_per_hosted_zone,route53_reusable_delegation_set_count,route53_traffic_policy_count,route53_traffic_policy_instance_count,route53_vpcs_per_hosted_zone,route53resolver_endpoint_count,route53resolver_rule_association_count,route53resolver_rule_count,s3_bucket_count,secretsmanager_secrets_count,sg_count,sns_pending_subscriptions_count,sns_subscriptions_per_topic,sns_topics_count,vpc_acls_per_vpc,vpc_count,vpc_subnets_per_vpc
  09-Mar-21 20:15:11 [INFO] botocore.credentials - Found credentials in shared credentials file: ~/.aws/credentials
  09-Mar-21 20:15:11 [INFO] aws_quota.prometheus - starting /metrics endpoint on port 8080
  09-Mar-21 20:15:11 [INFO] aws_quota.prometheus - collecting checks
  09-Mar-21 20:15:19 [INFO] aws_quota.prometheus - collected 110 checks
  09-Mar-21 20:15:19 [INFO] aws_quota.prometheus - refreshing limits
  09-Mar-21 20:16:34 [INFO] aws_quota.prometheus - limits refreshed
  09-Mar-21 20:16:34 [INFO] aws_quota.prometheus - refreshing current values
  09-Mar-21 20:18:15 [INFO] aws_quota.prometheus - current values refreshed
  ```

  The exporter will return the following metrics:

  - awsquota_$checkkey: the current value of each quota check
  - awsquota_$checkkey_limit: the limit value of each quota check
  - awsquota_$checkkey_duration_seconds: the time to get the current value of each quota check
  - awsquota_$checkkey_limit_duration_seconds: the time to get the limit value of each quota check
  - awsquota_check_count: the number of quota checks that are being executed
  - awsquota_check_limits_duration_seconds: the number of seconds that was necessary to query all quota limits
  - awsquota_check_currents_duration_seconds: the number of seconds that was necessary to query all current quota values
  - awsquota_info: info gauge that will expose the current AWS account and region as labels

  Depending on the check type, labels for the AWS account, the AWS region and the instance ID will be attached to the metric.

  Below you can find a few example metrics:

  ```


  awsquota_info{account="123456789",region="us-east-1"} 1.0


  awsquota_check_count 110.0


  awsquota_collect_checks_duration_seconds{account="123456789",region="us-east-1"} 7.885610818862915


  awsquota_asg_count_limit{account="123456789",region="us-east-1"} 200.0


  awsquota_ec2_on_demand_standard_count{account="123456789"} 22.0


  awsquota_elb_listeners_per_clb{account="123456789",instance="aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",region="us-east-1"} 10.0
  awsquota_elb_listeners_per_clb{account="123456789",instance="bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb",region="us-east-1"} 2.0
  ```

  As querying all quotas, depending on the number of resources to check, may take some time, the exporter works asynchronously. That means requesting the /metrics endpoint will return cached results and not trigger a recheck of all quotas. Instead all checks will be executed and refreshed in the background. That's why no metrics will be available directly after starting the exporter.

  Hence it doesn't make too much sense to scrape the /metrics every few seconds cause the values will only refresh once in a while. The check intervals of the background jobs can be adjusted to your needs using command line arguments.



  To enable autocompletion for all check keys, sub commands and their options, follow one of the next sections depending on the shell you use.



  Add this to your _~/.bashrc_:

  `eval "$(_AWS_QUOTA_CHECKER_COMPLETE=source_bash aws-quota-checker)"`



  Add this to your _~/.zshrc_:

  `eval "$(_AWS_QUOTA_CHECKER_COMPLETE=source_zsh aws-quota-checker)"`



  Add this to your _~/.config/fish/completions/aws-quota-checker.fish_:

  `eval "$(_AWS_QUOTA_CHECKER_COMPLETE=source_fish aws-quota-checker)"`



  Feel free to create a new issue with the _New Check_ label including a description which quota check you are missing.


pkgId: 3b3baf0fa08a6efe6950320536a482c3f7e5077aecb073edb4169b3277834b50
name: python-aws-rag-bot
arch: src
version: 0.1.16
epoch: 0
release: 1
summary: please add a summary manually as the author left a blank one
url: https://github.com/harvest2o-llc/aws-rag-bot
rpm_license: MIT
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-rag-bot-0.1.16-1.src.rpm
checksum_type: sha256
description:
  This is a RAG chatbot application based on AWS components and designed to be optimized for a serverless architecture
  and cost optimized for a high-volume mobile application use case.  The AWS Services being used are:
  - AWS Bedrock with the Titan LLM and Titan embeddings
  - OpenSearch (aka Elasticsearch) vector database - this is instance based but can be serverless (not implemented yet)

  The frameworks I created here abstract out a variety of components to enable easily testing variations.  This makes it easier to tune the implementation based on the
  content being use in my applications.  The goal is to play with different LLM's, different embeddings, parameters like temperature, top_p and more.
  Content loading also needed to be highly refined allowing me to control each source easily.

  This library is meant more to provide a complete working set of examples and less to be an out-of-the-box library to use as-is.
  Because this framework imports so many variants of embeddings, LLM models, etc. it is not suitable for a direct deployment into something like AWS Lambda... it is a :pig:.
  Serious package bloat.



  - **LangChain** - Great framework building Generative AI applications.
  - **LLM Model Support** - Defaults to AWS Bedrock Titan LLM, but supports other Bedrock models (LLama 2, Jurassic, Anthropic Claude) OpenAI (GTP-3.5 and GTP-4), Google Gemini
  - **LangChain LLM Callbacks** - Example of using LLM Callbacks, provided here for custom costing
  - **Conversational Memory** -- Designed to manage chat history memory from the client side - to support a serverless model
  - **OpenSearch** - an AWS hosted semantic search service which has a vector database that is valuable in the retrieval feature of RAG
  - **OpenSearch loading library** - making it easier to load multiple content sources into an OpenSearch vector database.
  - **Langchain LCEL Chains** - for more flexible chaining of steps in the RAG app
  - **Multiple embedding models** - Defaults to Bedrock Titan, OpenAI and Hugging Face and Cohere
  - **Web and directory crawlers** - for loading content into the vector DB.  Lots of fine-tuning to document selection features - whitelisting, black listing, etc.
  - **Prompt library management** - making it easier to implement query routing to optimize for specific domains of questions
  - **LangSmith logging** - for logging and debugging
  - **Ragas Evaluation** - A simple starter module that uses [ragas](https://docs.ragas.io/en/stable/) to run evaluations on the RAG chain configurations you want to compare.



  - Python 3.11 (may work on older, but this was the target version used)
  - AWS Account with keys defined in .aws/credentials file
  - AWS OpenSearch Domain created and accessible to the AWS account credentials above
  - AWS Bedrock with Titan Express LLM (or other LLM supported by this code) - you may need to request access
  - Ideally a LangChain (LangSmith) API Key defined in .env file (or removed if not using LangSmith) for logging and monitoring
  - If using google gemini or openai, you will need to have an account and keys for those services and have them defined in the .env file
  - Python dependencies installed (dependency manager for this project coming soon)


  This project uses Poetry to manage dependencies.  You can install it with the following command:
  ```bash
  pip install poetry
  ```

  Then you can install the dependencies with the following command:
  ```bash
  poetry install
  ```

  Alternatively, you can install the package from PyPi with the following command:
  ```bash
  pip install aws-rag-bot
  ```
  Where the PyPi package is available at https://pypi.org/project/aws-rag-bot/
  ****

  This is a very simple, high-level example.  Check out the rag_bot_code_samples.ipynb for a more.
  First step is to have content in your vector database.
  ```python
  from open_search_vector_db.aws_opensearch_vector_database import OpenSearchVectorDBLoader
  content_sources = [{"name": "Internal KB Docs", "type": "PDF", "location": "kb-docs"}]
  vectordb_loader = OpenSearchVectorDBLoader(os_endpoint=my_open_search_endpoint,
                                       index_name=my_index_name,
                                       data_sources=content_sources)

  vectordb_loader.load()
  ```

  Then you can start asking questions of it
  ```python
  from rag_chatbot import RagChatbot, LlmModelTypes
  from prompt_library import DefaultPrompts
  chatbot = RagChatbot(my_open_search_endpoint,
                       model_key=LlmModelTypes.BEDROCK_TITAN_EXPRESS,
                       prompt_model=NasaSpokespersonPrompts)
  chat_history = []
  question = "What...?" # Ask a question related to the content you loaded

  response = chatbot.ask_question(question, chat_history, verbose=True)
  print(response)
  ```



  You can use the tests/provision_test_index.py to create a test index in OpenSearch.  The content loaded
  supports the test cases in this project



  A very simple command line client program has been created as an example and tool to test.  It is called chatbot_client.py.
  It is a simple command line program that will ask a question and then print the response while retaining the chat history for context.

  ```bash
  python chatbot_client.py my-opensource-domain-name
  ```


  There are two test modules in the tests folder used to run through search and the RAG bot to make sure everything is working as well as provide
  some additional samples of how to use the framework.


  Ragas is one of a variety of evaluation tools for RAG applications.
  It can be used to evaluate both the retrieval and generation aspects of the RAG bot.
  With an evaluation tool you can then use this project's features to vary whatever aspects you need
  and compare the results to make decisions and tune.
  A simple example of this can be found in the tests folder.



  **Vector Database:**  May references show using Chroma and FAISS, but I needed a solution that worked well in a Lambda serverless environment.
  Ideally it would be at AWS keeping my stack uniform.
  - https://aws.amazon.com/what-is/vector-databases/

  Ultimately I chose OpenSearch because of cost, support by LangChain and a serverless version I plan to evaluate

  **Vector Database Loader:**  LangChain has a great library of DataLoaders for loading data into OpenSearch.  I wanted an effective way
  to scrape a website with help from this article chose to use Selenium.
  - https://www.comet.com/site/blog/langchain-document-loaders-for-web-data/

  I also used the directory loader and plan to implement cloud based directory loaders in the future.  Primarily S3 and Google Drive.

  **Langsmith Logging and Debugging:**  I used LangSmith for logging and debugging.  It is a great tool for this purpose.
  - https://docs.smith.langchain.com


pkgId: 01c7d66da2a40a4274850671674f801c83e8fe17f1bd9617f7d510945660f314
name: python-aws-request-signer
arch: src
version: 1.2.0
epoch: 0
release: 1
summary: A python library to sign AWS requests using AWS Signature V4.
url: https://www.github.com/iksteen/aws-request-signer
rpm_license: MIT
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-request-signer-1.2.0-1.src.rpm
checksum_type: sha256
description:
  > A python library to sign AWS requests using AWS Signature V4.

  This small python library serves only purpose: Helping you sign HTTP
  requests for use with AWS (and compatible) services. The library is
  unopinionated and should work with just about anything that makes HTTP
  requests (requests, aiohttp).

  It supports generating authorization headers for HTTP requests,
  pre-signing URLs so you can easily use them elsewhere and signing S3
  POST policies for use in HTML forms.

  This library has no requirements, but comes with an authentication
  helper for the requests package.



  `aws-request-signer` is available from pypi:

  ```sh
  pip install aws-request-signer
  ```



  Here's an example of how to use the library to sign a request to upload a file to a
  [minio](https://minio.io/) S3 bucket running on your local machine:

  ```python
  import hashlib

  import requests
  from aws_request_signer import AwsRequestSigner

  AWS_REGION = ""
  AWS_ACCESS_KEY_ID = "minio"
  AWS_SECRET_ACCESS_KEY = "minio123"

  URL = "http://127.0.0.1:9000/demo/hello_world.txt"


  content = b"Hello, World!\n"
  content_hash = hashlib.sha256(content).hexdigest()


  request_signer = AwsRequestSigner(
      AWS_REGION, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, "s3"
  )


  headers = {"Content-Type": "text/plain", "Content-Length": str(len(content))}


  headers.update(
      request_signer.sign_with_headers("PUT", URL, headers, content_hash)
  )


  r = requests.put(URL, headers=headers, data=content)
  r.raise_for_status()
  ```

  _For more examples and usage, please refer to
  [demo.py](https://github.com/iksteen/aws-request-signer/blob/master/demo.py)._



  For development purposes, you can clone the repository and use
  [poetry](https://poetry.eustace.io/) to install and maintain the
  dependencies. There is no test suite. It comes with a set of pre-commit
  hooks that can format (isort, black) and check your code (mypy, flake8)
  automatically.

  ```sh
  git clone git@github.com:iksteen/aws-request-signer.git
  cd aws-request-signer
  poetry install -E demo
  poetry run pre-commit install
  ```



  * 1.2.0
      * Add support for passing a security token to `AwsRequestSigner`
        and `AwsAuth` helper for request. Thanks @ajpl.
  * 1.1.1
      * Use `quote` instead of the default `quote_plus` so query
        arguments that contain spaces work (thanks @eraser-77).
  * 1.1.0
      * Minimum supported python version is now 3.6.1.
      * Assume empty content when signing a HEAD or DELETE request
        just as we do when signing a GET request. Thanks @alvassin!
      * Fix bug where `sign_with_headers` did not include valueless
        query arguments in the signing process (f.e. `?acl`).
  * 1.0.0
      * Initial Release.



  Ingmar Steen – [@iksteen](https://twitter.com/iksteen)

  Distributed under the MIT license. See ``LICENSE`` for more information.

  [https://github.com/iksteen/](https://github.com/iksteen/)



  1. Fork it (<https://github.com/iksteen/aws-request-signer/fork>)
  2. Create your feature branch (`git checkout -b feature/fooBar`)
  3. Commit your changes (`git commit -am 'Add some fooBar'`)
  4. Push to the branch (`git push origin feature/fooBar`)
  5. Create a new Pull Request


pkgId: faffdc3f75b7ba91c9630dbe3ee0ecbeed5b632cad8bf83786dd185cbc942707
name: python-aws-requests-auth-stubs
arch: src
version: 0.4.3.2
epoch: 0
release: 1
summary: PEP 561 stubs for aws-requests-auth
url: https://github.com/YonatanGreenfeld/aws-requests-auth-stubs
rpm_license: MIT
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-requests-auth-stubs-0.4.3.2-1.src.rpm
checksum_type: sha256
description:
  <a href="https://github.com/YonatanGreenfeld/aws-requests-auth-stubs/blob/main/LICENSE"><img alt="License: MIT" src="https://black.readthedocs.io/en/stable/_static/license.svg"></a>
  <a href="http://mypy-lang.org/"><img alt="Checked with mypy" src="http://www.mypy-lang.org/static/mypy_badge.svg"></a>
  <a href="https://github.com/psf/black"><img alt="Code style: black" src="https://img.shields.io/badge/code%20style-black-000000.svg"></a>

  PEP-561 stub package for the [aws-requests-auth](https://github.com/DavidMuller/aws-requests-auth) package.


pkgId: 3fcaf95ff7d69900445fe285be83b88ebfd5a2cd33dddcec93dbcc83cbb84651
name: python-aws-s3-tools
arch: src
version: 0.3.0
epoch: 0
release: 1
summary: AWS S3 tools package
url: https://github.com/dlite-tools/aws-s3-tools
rpm_license: MIT
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-s3-tools-0.3.0-1.src.rpm
checksum_type: sha256
description:
  You can install AWS S3 Tools from PyPi with `pip` or your favorite package manager:
  ```shell
  pip install aws-s3-tools
  ```
  Add the ``-U`` switch to update to the current version, if AWS S3 Tools is already installed.
  If you want to use the **progress bar** feature when downloading or uploading,
  you need to install an extra dependency.
  ```shell
  pip install aws-s3-tools[progress]


pkgId: 3355bcf5430d2502fce5dbdddf4f52d5bfe8dd43a997318914fab7db94a91f23
name: python-aws-sam-cli-local
arch: src
version: 1.70.0
epoch: 0
release: 1
summary: Simple wrapper around AWS SAM CLI for use with LocalStack
url: https://github.com/localstack/aws-sam-cli-local
rpm_license: Apache License 2.0
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-sam-cli-local-1.70.0-1.src.rpm
checksum_type: sha256
description:
  This project provides the `samlocal` command line, a simple wrapper around the [AWS SAM CLI](https://github.com/aws/aws-sam-cli) for use with [LocalStack](https://github.com/localstack/localstack).



  Simply use `pip` to install `samlocal` as a Python library on your machine:

  ```
  pip install aws-sam-cli-local
  ```



  The `samlocal` command has the exact same usage as the underlying `sam` command. The main difference is that for commands like `samlocal deploy` the operations will be executed against the LocalStack endpoints (`http://localhost:4566` by default) instead of real AWS endpoints.

  ```
  samlocal --help
  ```



  * `AWS_ENDPOINT_URL`: URL at which the `boto3` client can reach LocalStack, e.g. `http://localhost.localstack.cloud:4566` (default: `http://localhost:4566`)
  * `EDGE_PORT`: **Deprecated** Port number under which the LocalStack edge service is available (default: `4566`)
  * `LOCALSTACK_HOSTNAME`: **Deprecated** Host under which the LocalStack edge service is available (default: `localhost`)



  * v1.70.0: Fix regex pattern to detect ECR URLs with dashes
  * v1.69.0: Fix repo related cli options and add support to Lambdas with `Image` type
  * v1.68.0: Support `AWS_ENDPOINT_URL` for configuring the `boto3.client` endpoint
  * v1.67.0: Patch underlying `boto3.Session.client` instead of `boto3.client`
  * v1.55.0: Fix s3 URl detection when using a nested template
  * v1.53.1: Fix logic around local URLs for ECR image repositories
  * v1.1.0.1: Minor fix, release initial version of `samlocal` command
  * v1.1.0: Initial version



  This software library is released under the Apache License, Version 2.0.


pkgId: e54dff4da656f724924310d719d592d46d9f56a1a6afda6d857a7d04fcb80f2e
name: python-aws-satella
arch: src
version: 2.4
epoch: 0
release: 1
summary: Integration of Satella's metrics with AWS CloudWatch
url: https://github.com/piotrmaslanka/aws-satella
rpm_license: MIT License
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-satella-2.4-1.src.rpm
checksum_type: sha256
description:
  [![PyPI](https://img.shields.io/pypi/pyversions/aws-satella.svg)](https://pypi.python.org/pypi/aws-satella)
  [![PyPI version](https://badge.fury.io/py/aws-satella.svg)](https://badge.fury.io/py/aws-satella)
  [![PyPI](https://img.shields.io/pypi/implementation/aws-satella.svg)](https://pypi.python.org/pypi/aws-satella)
  [![License](https://img.shields.io/pypi/l/aws-satella)](https://github.com/piotrmaslanka/aws-satella)
  [![Build Status](https://app.travis-ci.com/piotrmaslanka/aws-satella.svg?branch=master)](https://travis-ci.com/piotrmaslanka/aws-satella)
  [![Test Coverage](https://api.codeclimate.com/v1/badges/d460105ad44269de543b/test_coverage)](https://codeclimate.com/github/piotrmaslanka/aws-satella/test_coverage)
  [![Maintainability](https://api.codeclimate.com/v1/badges/d460105ad44269de543b/maintainability)](https://codeclimate.com/github/piotrmaslanka/aws-satella/maintainability)
  [![Issue Count](https://codeclimate.com/github/piotrmaslanka/aws-satella/badges/issue_count.svg)](https://codeclimate.com/github/piotrmaslanka/aws-satella)
  [![Documentation Status](https://readthedocs.org/projects/aws-satella/badge/?version=latest)](http://aws-satella.readthedocs.io/en/latest/?badge=latest)

  A library to export Satella's metrics to AWS CloudWatch



  ```bash
  pip install aws-satella
  ```



  ```python
  import sys
  from aws_satella import AWSSatellaExporterThread, InitializationError


  try:
      aws = AWSSatellaExporterThread('AppNamespace')
      aws.start()
  except InitializationError:
      print('Could not initialize the boto3 client')
      sys.exit(1)

  ```

  This spawns a daemonic thread. For details,
  refer to the [docs](https://aws-satella.readthedocs.io).

  You can additionally use
  ```python
  from aws_satella import start_if_not_started

  start_if_not_started(*args, **kwargs)
  ```
  Both `args` and `kwargs` will be passed to constructor.
  This will initialize such thread, if one does not exist already.

  This also supports easy Django configuration, for details go
  [read the docs](https://aws-satella.readthedocs.org).



  Change log was moved [here](https://aws-satella.readthedocs.io/en/latest/changelog.html).



  My special thanks go out to the team at
  [Mailerrize](https://mailerrize.com)
  for their support.


pkgId: 0aaa26743d6f52aa0acc9501bf6a8bb7b0cfa9f9b0ab95bc57b6170a6b1b2bf4
name: python-aws-sdk-polars
arch: src
version: 0.1.4
epoch: 0
release: 1
url: https://github.com/MacHu-GWU/aws_sdk_polars-project
rpm_license: MIT
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-sdk-polars-0.1.4-1.src.rpm
checksum_type: sha256
summary:
  An open-source Python initiative that harnesses the lightning-fast capabilities of the Polars library within the AWS ecosystem.


pkgId: 22a4ceb3bfd0f753d2ae1645be0ebbf3d1c43b69b7bd2e3d4605bbdef9ae664a
name: python-aws-secrets
arch: src
version: 0.1.10
epoch: 0
release: 1
summary: Python library for resolving secrets from AWS Secrets Manager
url: https://github.com/davidcroda/aws_secrets
rpm_license: MIT License
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-secrets-0.1.10-1.src.rpm
checksum_type: sha256
description:
  This library allows you to use credentials stored in AWS Secrets Manager within
  your code. It will lazily resolve secret values when they are evaluated, or resolve
  all secrets when AWSCredential.resolve_secrets() is called.


pkgId: 2cbdcbe9b7b9ada6628e5cb797a75ab0ce6fea57e508cbabecee033bb94773b9
name: python-aws-secretsmanager-caching
arch: src
version: 1.1.3
epoch: 0
release: 1
summary: Client-side AWS Secrets Manager caching library
url: https://github.com/aws/aws-secretsmanager-caching-python
rpm_license: None
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-secretsmanager-caching-1.1.3-1.src.rpm
checksum_type: sha256
description:
  [![Build](https://github.com/aws/aws-secretsmanager-caching-python/actions/workflows/python-package.yml/badge.svg?event=push)](https://github.com/aws/aws-secretsmanager-caching-python/actions/workflows/python-package.yml)
  [![codecov](https://codecov.io/github/aws/aws-secretsmanager-caching-python/branch/master/graph/badge.svg?token=DkTHUP8lv5)](https://codecov.io/github/aws/aws-secretsmanager-caching-python)

  The AWS Secrets Manager Python caching client enables in-process caching of secrets for Python applications.





  To use this client you must have:

  * Python 3.7 or newer.  Use of Python versions 3.6 or older are not supported.
  * An Amazon Web Services (AWS) account to access secrets stored in AWS Secrets Manager.
    * **To create an AWS account**, go to [Sign In or Create an AWS Account](https://portal.aws.amazon.com/gp/aws/developer/registration/index.html) and then choose **I am a new user.** Follow the instructions to create an AWS account.

    * **To create a secret in AWS Secrets Manager**, go to [Creating Secrets](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_create-basic-secret.html) and follow the instructions on that page.

    * This library makes use of botocore, the low-level core functionality of the boto3 SDK.  For more information on boto3 and botocore, please review the [AWS SDK for Python](https://aws.amazon.com/sdk-for-python/) and [Botocore](https://botocore.amazonaws.com/v1/documentation/api/latest/index.html) documentation.


  This library requires the following standard dependencies:
  * botocore
  * setuptools_scm
  * setuptools

  For development and testing purposes, this library requires the following additional dependencies:
  * pytest
  * pytest-cov
  * pytest-sugar
  * codecov
  * pylint
  * sphinx
  * flake8
  * tox

  Please review the `requirements.txt` and `dev-requirements.txt` file for specific version requirements.


  Installing the latest release via **pip**:
  ```bash
  $ pip install aws-secretsmanager-caching
  ```

  Installing the latest development release:
  ```bash
  $ git clone https://github.com/aws/aws-secretsmanager-caching-python.git
  $ cd aws-secretsmanager-caching-python
  $ python setup.py install
  ```



  Assuming that you have Python and virtualenv installed, set up your environment and install the required dependencies like this instead of the `pip install aws_secretsmanager_caching` defined above:

  ```bash
  $ git clone https://github.com/aws/aws-secretsmanager-caching-python.git
  $ cd aws-secretsmanager-caching-python
  $ virtualenv venv
  ...
  $ . venv/bin/activate
  $ pip install -r requirements.txt -r dev-requirements.txt
  $ pip install -e .
  ```


  You can run tests in all supported Python versions using tox. By default, it will run all of the unit and integration tests, but you can also specify your own arguments to past to `pytest`.
  ```bash
  $ tox # runs integ/unit tests, flake8 tests and pylint tests
  $ tox -- test/unit/test_decorators.py # runs specific test file
  $ tox -e py37 -- test/integ/ # runs specific test directory
  ```


  You can locally-generate the Sphinx-based documentation via:
  ```bash
  $ tox -e docs
  ```
  Which will subsequently be viewable at `file://${CLONE_DIR}/.tox/docs_out/index.html`


  Using the client consists of the following steps:
  1.  Instantiate the client while optionally passing in a `SecretCacheConfig()` object to the `config` parameter.  You can also pass in an existing `botocore.client.BaseClient` client to the client parameter.
  2.  Request the secret from the client instance.
  ```python
  import botocore
  import botocore.session
  from aws_secretsmanager_caching import SecretCache, SecretCacheConfig

  client = botocore.session.get_session().create_client('secretsmanager')
  cache_config = SecretCacheConfig() # See below for defaults
  cache = SecretCache(config=cache_config, client=client)

  secret = cache.get_secret_string('mysecret')
  ```


  You can configure the cache config object with the following parameters:
  * `max_cache_size` - The maximum number of secrets to cache.  The default value is `1024`.
  * `exception_retry_delay_base` - The number of seconds to wait after an exception is encountered and before retrying the request.  The default value is `1`.
  * `exception_retry_growth_factor` - The growth factor to use for calculating the wait time between retries of failed requests.  The default value is `2`.
  * `exception_retry_delay_max` - The maximum amount of time in seconds to wait between failed requests.  The default value is `3600`.
  * `default_version_stage` - The default version stage to request.  The default value is `'AWSCURRENT'`
  * `secret_refresh_interval` - The number of seconds to wait between refreshing cached secret information.  The default value is `3600.0`.
  * `secret_cache_hook` - An implementation of the SecretCacheHook abstract class.  The default value is `None`.


  The library also includes several decorator functions to wrap existing function calls with SecretString-based secrets:
  * `@InjectedKeywordedSecretString` - This decorator expects the secret id and cache as the first and second arguments, with subsequent arguments mapping a parameter key from the function that is being wrapped to a key in the secret.  The secret being retrieved from the cache must contain a SecretString and that string must be JSON-based.
  * `@InjectSecretString` - This decorator also expects the secret id and cache as the first and second arguments.  However, this decorator simply returns the result of the cache lookup directly to the first argument of the wrapped function.  The secret does not need to be JSON-based but it must contain a SecretString.
  ```python
  from aws_secretsmanager_caching import SecretCache
  from aws_secretsmanager_caching import InjectKeywordedSecretString, InjectSecretString

  cache = SecretCache()

  @InjectKeywordedSecretString(secret_id='mysecret', cache=cache, func_username='username', func_password='password')
  def function_to_be_decorated(func_username, func_password):
      print('Something cool is being done with the func_username and func_password arguments here')
      ...

  @InjectSecretString('mysimplesecret', cache)
  def function_to_be_decorated(arg1, arg2, arg3):
      
      
  ```


  We use GitHub issues for tracking bugs and caching library feature requests and have limited bandwidth to address them. Please use these community resources for getting help:
  * Ask a question on [Stack Overflow](https://stackoverflow.com/) and tag it with [aws-secrets-manager](https://stackoverflow.com/questions/tagged/aws-secrets-manager).
  * Open a support ticket with [AWS Support](https://console.aws.amazon.com/support/home#/)
  * if it turns out that you may have found a bug, please [open an issue](https://github.com/aws/aws-secretsmanager-caching-python/issues/new).


  This library is licensed under the Apache 2.0 License.


pkgId: 9ebfeeada01795fe2f162614727fbd8cca3d088a726a8801115897e37297c34c
name: python-aws-service-catalog-puppet
arch: src
version: 0.249.0
epoch: 0
release: 1
summary: Making it easier to deploy ServiceCatalog products
url: https://service-catalog-tools-workshop.com/
rpm_license: None
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-service-catalog-puppet-0.249.0-1.src.rpm
checksum_type: sha256
description:
  ![logo](./docs/logo.png)



  [![codecov](https://codecov.io/gh/awslabs/aws-service-catalog-puppet/branch/master/graph/badge.svg?token=e8M7mdsmy0)](https://codecov.io/gh/awslabs/aws-service-catalog-puppet)



  This is a python3 framework that makes it easier to share multi region AWS Service Catalog portfolios and makes it
  possible to provision products into accounts declaratively using a metadata based rules engine.

  With this framework you define your accounts in a YAML file.  You give each account a set of tags, a default region and
  a set of enabled regions.

  Once you have done this you can define portfolios should be shared with each set of accounts using the tags and you
  can specify which regions the shares occur in.

  In addition to this, you can also define products that should be provisioned into accounts using the same tag based
  approach.  The framework will assume role into the target account and provision the product on your behalf.




  You can read the [installation how to](https://service-catalog-tools-workshop.com/30-how-tos/10-installation/30-service-catalog-puppet.html)
  or you can read through the [every day use](https://service-catalog-tools-workshop.com/30-how-tos/50-every-day-use.html)
  guides.

  You can read the [documentation](https://aws-service-catalog-puppet.readthedocs.io/en/latest/) to understand the inner
  workings.




  The framework is one of a pair.  The other is [aws-service-catalog-factory](https://github.com/awslabs/aws-service-catalog-factory).
  With Service Catalog Factory you can create pipelines that deploy multi region portfolios very easily.



  This library is licensed under the Apache 2.0 License.


pkgId: 3eea4cc09eef0545f09ca40612396945ada1db5aa6819ac78d87816c9e931a54
name: python-aws-session
arch: src
version: 5.5.0
epoch: 0
release: 1
url: https://github.com/qoomon/aws-session
rpm_license: MIT License
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-session-5.5.0-1.src.rpm
checksum_type: sha256
summary:
  A CLI to generate session credentials based on ~/.aws/config profiles and store them as profile in ~/.aws/credentials file

description:
  [![PyPI](https://img.shields.io/pypi/v/aws-session)](https://pypi.org/project/aws-session/)

  A CLI to generate and store session credentials in `~/.aws/credentials` file, based on `~/.aws/config` profiles



  `pip3 install aws-session`


  ```
  get session credentials:

      aws-session get [--profile/-p <profile_name>]

          --profile/-p <profile_name> : select profile ['default']
          --force/-f                  : force new session

      To create MFA user sessions just add `mfa_serial` to profile config in ~/.aws/config profiles

  list session profiles:

      aws-session list

  purge expired session profiles:

      aws-session purge

          --force/-f                  : purge all session profiles regardles of expiration

  print help

      aws-session help
  ```




  ```
  export PATH="${PATH}:/Users/${USER}/Library/Python/3.7/bin"
  export PYTHONPATH="${PYTHONPATH}:/Users/${USER}/Library/Python/3.7/bin"
  pip3 install --user -r requirements.txt
  pip3 install --user -r requirements-dev.txt
  ```


  `python3 -m aws_session get`


  `python3 setup.py clean --all sdist bdist_wheel`


  `pip3 install --force-reinstall --no-deps dist/aws_session-*-py3-none-any.whl`


  `twine upload dist/*`


pkgId: 270a11006d54ae50c9e90a3177b3d4005b97f22f0dac14380f803c203b150b4f
name: python-aws-sns-message-validator
arch: src
version: 0.0.5
epoch: 0
release: 1
summary: Validator for AWS SNS messages.
url: https://github.com/wlwg/aws-sns-message-validator
rpm_license: UNKNOWN
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-sns-message-validator-0.0.5-1.src.rpm
checksum_type: sha256
description:
  PyPI: https://pypi.org/project/aws-sns-message-validator/


  An HTTP endpoint for AWS SNS needs to validate the received messages before processing them which involves some non-trivial logic, especially [signature verification](https://docs.aws.amazon.com/sns/latest/dg/SendMessageToHttp.verify.signature.html). In terms of implementation, AWS does not offer any help with SNS message validation in their SDK for Python ([issue](https://github.com/boto/boto3/issues/1469)) nor does it provide example code in the documentation (example code is only available [in Java](https://docs.aws.amazon.com/sns/latest/dg/SendMessageToHttp.example.java.html)). Therefore Python developers would need to invent their own wheels.

  To solve this problem, this repository offers an SNS message validator which is implemented according to the guide on [the official AWS documentation](https://docs.aws.amazon.com/sns/latest/dg/sns-http-https-endpoint-as-subscriber.html), and offers [example code](flask_example.py) of how to use it to implement an HTTP endpoint for SNS.



  - Python >= 3.6


  `pip install aws-sns-message-validator`


  Refer to the example code [`flask_example.py`](flask_example.py) to see how to use this package in your SNS http endpoint. In order to quickly try out the example code, follow the steps below:
  - Make sure you have Python>=3.6 installed. (Create a virtual environment if you want to.)
  - Checkout this repo and install dev dependencies by `python3 -m pip install -r requirements.txt`
  - Run `FLASK_APP=flask_example.py flask run --port=5000` to start an http server.
  - Use `ngrok` to expose the local server to the public internet (`./ngrok http -bind-tls=true localhost:5000`). Now you should get a public endpoint (`https://xxxxxxxx.ngrok.io`) that can be set as a subscriber of an SNS topic.


  Feel free to create an issue if you found a bug or have a feature request.


pkgId: 10ce43c78eba1c4ff60acf4abf0351c1063926afa0345cae846bb4a43c12766d
name: python-aws-solutions-constructs.aws-alb-fargate
arch: src
version: 2.74.0
epoch: 0
release: 1
summary: CDK Constructs for Application Load Balancer to AWS Fargate integration
url: https://github.com/awslabs/aws-solutions-constructs.git
rpm_license: Apache-2.0
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-aws-solutions-constructs.aws-alb-fargate-2.74.0-1.src.rpm
checksum_type: sha256
description:
  <!--END STABILITY BANNER-->
  | **Reference Documentation**:| <span style="font-weight: normal">https://docs.aws.amazon.com/solutions/latest/constructs/</span>|
  |:-------------|:-------------|
  <div style="height:8px"></div>
  | **Language**     | **Package**        |
  |:-------------|-----------------|
  |![Python Logo](https://docs.aws.amazon.com/cdk/api/latest/img/python32.png) Python|`aws_solutions_constructs.aws_alb_fargate`|
  |![Typescript Logo](https://docs.aws.amazon.com/cdk/api/latest/img/typescript32.png) Typescript|`@aws-solutions-constructs/aws-alb-fargate`|
  |![Java Logo](https://docs.aws.amazon.com/cdk/api/latest/img/java32.png) Java|`software.amazon.awsconstructs.services.albfargate`|

  This AWS Solutions Construct implements an an Application Load Balancer to an AWS Fargate service
  Here is a minimal deployable pattern definition:
  Typescript
  ```python
  import { Construct } from 'constructs';
  import { Stack, StackProps } from 'aws-cdk-lib';
  import { AlbToFargate, AlbToFargateProps } from '@aws-solutions-constructs/aws-alb-fargate';
  import * as acm from 'aws-cdk-lib/aws-certificatemanager';
  const certificate = acm.Certificate.fromCertificateArn(
      this,
      'existing-cert',
      "arn:aws:acm:us-east-1:123456789012:certificate/11112222-3333-1234-1234-123456789012"
  );
  const constructProps: AlbToFargateProps = {
      ecrRepositoryArn: "arn:aws:ecr:us-east-1:123456789012:repository/your-ecr-repo",
      ecrImageVersion: "latest",
      listenerProps: {
          certificates: [certificate]
      },
      publicApi: true
  };
  // Note - all alb constructs turn on ELB logging by default, so require that an environment including account
  // and region be provided when creating the stack
  //
  // new MyStack(app, 'id', {env: {account: '123456789012', region: 'us-east-1' }});
  new AlbToFargate(this, 'new-construct', constructProps);
  ```
  Python
  ```python
  from aws_solutions_constructs.aws_alb_fargate import AlbToFargate, AlbToFargateProps
  from aws_cdk import (
      aws_certificatemanager as acm,
      aws_elasticloadbalancingv2 as alb,
      Stack
  )
  from constructs import Construct

  certificate = acm.Certificate.from_certificate_arn(
        self,
        'existing-cert',
        "arn:aws:acm:us-east-1:123456789012:certificate/11112222-3333-1234-1234-123456789012"
      )




  AlbToFargate(self, 'new-construct',
                  ecr_repository_arn="arn:aws:ecr:us-east-1:123456789012:repository/your-ecr-repo",
                  ecr_image_version="latest",
                  listener_props=alb.BaseApplicationListenerProps(
                      certificates=[certificate],
                  ),
                  public_api=True)
  ```
  Java
  ```java
  import software.constructs.Construct;
  import java.util.List;
  import software.amazon.awscdk.Stack;
  import software.amazon.awscdk.StackProps;
  import software.amazon.awscdk.services.elasticloadbalancingv2.*;
  import software.amazon.awsconstructs.services.albfargate.*;
  // The code that defines your stack goes here
  // Obtain a pre-existing certificate from your account
  ListenerCertificate listenerCertificate = ListenerCertificate
          .fromArn("arn:aws:acm:us-east-1:123456789012:certificate/11112222-3333-1234-1234-123456789012");
  // Note - all alb constructs turn on ELB logging by default, so require that an environment including account
  // and region be provided when creating the stack
  //
  // new MyStack(app, "id", StackProps.builder()
  //         .env(Environment.builder()
  //                 .account("123456789012")
  //                 .region("us-east-1")
  //                 .build());
  new AlbToFargate(this, "AlbToFargatePattern", new AlbToFargateProps.Builder()
          .ecrRepositoryArn("arn:aws:ecr:us-east-1:123456789012:repository/your-ecr-repo")
          .ecrImageVersion("latest")
          .listenerProps(new BaseApplicationListenerProps.Builder()
                  .certificates(List.of(listenerCertificate))
                  .build())
          .publicApi(true)
          .build());
  ```

  | **Name**     | **Type**        | **Description** |
  |:-------------|:----------------|-----------------|
  | publicApi | boolean | Whether the construct is deploying a private or public API. This has implications for the VPC and ALB. |
  | loadBalancerProps? | [elasticloadbalancingv2.ApplicationLoadBalancerProps](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_elasticloadbalancingv2.ApplicationLoadBalancerProps.html) | Optional custom properties for a new loadBalancer. Providing both this and existingLoadBalancer is an error. This cannot specify a VPC, it will use the VPC in existingVpc or the VPC created by the construct. |
  | existingLoadBalancerObj? | [elasticloadbalancingv2.ApplicationLoadBalancer](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_elasticloadbalancingv2.ApplicationLoadBalancer.html) | [existing Application Load Balancer to incorporate into the construct architecture. Providing both this and loadBalancerProps is an error. The VPC containing this loadBalancer must match the VPC provided in existingVpc.|
  | listenerProps? | [ApplicationListenerProps](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_elasticloadbalancingv2.ApplicationListenerProps.html) | Props to define the listener. Must be provided when adding the listener to an ALB (eg - when creating the alb), may not be provided when adding a second target to an already established listener. When provided, must include either a certificate or protocol: HTTP |
  | targetGroupProps? | [ApplicationTargetGroupProps](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_elasticloadbalancingv2.ApplicationTargetGroupProps.html) | Optional custom properties for a new target group. If your application requires end to end encryption, then you should set the protocol attribute to [elb.ApplicationProtocol.HTTPS](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_elasticloadbalancingv2.ApplicationProtocol.html) and use a container that can accept HTTPS traffic. |
  | ruleProps? | [AddRuleProps](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_elasticloadbalancingv2.AddRuleProps.html) | Rules for directing traffic to the target being created. Must not be specified for the first listener added to an ALB, and must be specified for the second target added to a listener. Add a second target by instantiating this construct a second time and providing the existingAlb from the first instantiation. |
  | vpcProps? | [ec2.VpcProps](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_ec2.VpcProps.html) | Optional custom properties for a VPC the construct will create. This VPC will be used by the new ALB and any Private Hosted Zone the construct creates (that's why loadBalancerProps and privateHostedZoneProps can't include a VPC). Providing both this and existingVpc is an error. |
  | existingVpc? | [ec2.IVpc](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_ec2.IVpc.html) | An existing VPC in which to deploy the construct. Providing both this and vpcProps is an error. If the client provides an existing load balancer and/or existing Private Hosted Zone, those constructs must exist in this VPC. |
  | logAlbAccessLogs? | boolean| Whether to turn on Access Logs for the Application Load Balancer. Uses an S3 bucket with associated storage costs.Enabling Access Logging is a best practice. default - true |
  | albLoggingBucketProps? | [s3.BucketProps](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_s3.BucketProps.html) | Optional properties to customize the bucket used to store the ALB Access Logs. Supplying this and setting logAccessLogs to false is an error. @default - none |
  | clusterProps? | [ecs.ClusterProps](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_ecs.ClusterProps.html) | Optional properties to create a new ECS cluster. To provide an existing cluster, use the cluster attribute of fargateServiceProps. |
  | ecrRepositoryArn? | string | The arn of an ECR Repository containing the image to use to generate the containers. Either this or the image property of containerDefinitionProps must be provided. format: arn:aws:ecr:*region*:*account number*:repository/*Repository Name* |
  | ecrImageVersion? | string | The version of the image to use from the repository. Defaults to 'Latest' |
  | containerDefinitionProps? | [ecs.ContainerDefinitionProps | any](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_ecs.ContainerDefinitionProps.html) | Optional props to define the container created for the Fargate Service (defaults found in fargate-defaults.ts) |
  | fargateTaskDefinitionProps? | [ecs.FargateTaskDefinitionProps | any](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_ecs.FargateTaskDefinitionProps.html) | Optional props to define the Fargate Task Definition for this construct  (defaults found in fargate-defaults.ts) |
  | fargateServiceProps? | [ecs.FargateServiceProps | any](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_ecs.FargateServiceProps.html) | Optional properties to override default values for the Fargate service. Service will set up in the Public or Isolated subnets of the VPC by default, override that (e.g. - choose Private subnets) by setting vpcSubnets on this object. |
  | existingFargateServiceObject? | [ecs.FargateService](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_ecs.FargateService.html) | A Fargate Service already instantiated (probably by another Solutions Construct). If this is specified, then no props defining a new service can be provided, including: existingImageObject, ecrImageVersion, containerDefinitionProps, fargateTaskDefinitionProps, ecrRepositoryArn, fargateServiceProps, clusterProps, existingClusterInterface |
  | existingContainerDefinitionObject? | [ecs.ContainerDefinition](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_ecs.ContainerDefinition.html) | A container definition already instantiated as part of a Fargate service. This must be the container in the existingFargateServiceObject |

  | **Name**     | **Type**        | **Description** |
  |:-------------|:----------------|-----------------|
  | vpc | [ec2.IVpc](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_ec2.IVpc.html) | The VPC used by the construct (whether created by the construct or providedb by the client) |
  | loadBalancer | [elasticloadbalancingv2.ApplicationLoadBalancer](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_elasticloadbalancingv2.ApplicationLoadBalancer.html) | The Load Balancer used by the construct (whether created by the construct or provided by the client) |
  | listener | [elb.ApplicationListener](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_elasticloadbalancingv2.ApplicationListener.html) | The listener used by this pattern. |
  | service | [ecs.FargateService](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_ecs.FargateService.html) | The AWS Fargate service used by this construct (whether created by this construct or passed to this construct at initialization) |
  | container | [ecs.ContainerDefinition](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_ecs.ContainerDefinition.html) | The container associated with the AWS Fargate service in the service property. |

  Out of the box implementation of the Construct without any override will set the following defaults:

  * Creates or configures an Application Load Balancer with:
    * Required listeners
    * New target group with routing rules if appropriate

  * Sets up an AWS Fargate service as a target of the Application Load Balancer
    * Uses the existing service if provided
    * Creates a new service if none provided.
      * Service will run in isolated subnets if available, then private subnets if available and finally public subnets


