amazonka alternatives and similar packages
Based on the "AWS" category.
Alternatively, view amazonka alternatives based on common mentions on social networks and blogs.
aws9.7 0.0 amazonka VS awsAmazon Web Services for Haskell
serverless-haskell9.6 0.0 amazonka VS serverless-haskellDeploying Haskell applications to AWS Lambda with Serverless
stratosphere9.5 6.2 amazonka VS stratosphereHaskell EDSL and type-checker for AWS CloudFormation templates
eventful-dynamodb9.3 0.0 amazonka VS eventful-dynamodbEvent Sourcing library for Haskell
ec2-unikernel8.8 0.0 amazonka VS ec2-unikernelTool for uploading unikernels into EC2
wolf8.7 0.0 amazonka VS wolfWolf is a wrapper around Amazon Simple Workflow Service.
aws-sdk8.7 0.0 amazonka VS aws-sdkAWS SDK for Haskell
amazonka-s3-streamingProvides a conduit based interface to uploading data to S3 using the Multipart API
aws-lambda8.0 0.0 amazonka VS aws-lambdaHaskell bindings for AWS Lambda
s3-signer7.9 0.0 amazonka VS s3-signer:cloud: Presigned S3 URLs for Haskell
aws-kinesis-client7.8 0.0 amazonka VS aws-kinesis-clientA producer/consumer client library for Kinesis
aws-general7.7 0.0 amazonka VS aws-generalHaskell Bindings for AWS General API
aws-ec27.7 0.0 amazonka VS aws-ec2Now maintained by: See https://github.com/memcachier/aws-ec2
aws-kinesis7.5 0.0 amazonka VS aws-kinesisHaskell Bindings for AWS Kinesis
aws-kinesis-reshard7.4 0.0 amazonka VS aws-kinesis-reshardA Kinesis resharding client
aws-sns7.1 0.0 amazonka VS aws-snsHaskell Bindings for AWS SNS
credentials7.0 0.0 amazonka VS credentialsManagement and Distribution of Secret Credentials
aws-performance-testsPerformance Tests for the Haskell Bindings for Amazon Web Services (AWS)
loup6.9 0.0 amazonka VS loupSimple Workpools
aws-sign46.5 0.0 amazonka VS aws-sign4Haskell implementation of the AWS Signature V4 protocol for signing HTTP requests
aws-configuration-toolsConfiguration types, parsers and renderers for AWS services using configuration-tools
aws-cloudfront-signerHaksell library package for signing URL requests to the AWS CloudFront service
aws-elastic-transcoderextension to the Haskell AWS repository to interface to the AWS Elastic Transcoder service
aws-route535.8 0.0 amazonka VS aws-route53A Haskell AWS Route53 client library
aws-ec2-knownhosts4.4 2.1 amazonka VS aws-ec2-knownhostsAWS EC2 knownhost management tools
aws-sdk-text-converterThe text converter for aws-sdk.
aws-dynamodb-conduit2.1 0.0 amazonka VS aws-dynamodb-conduitConduit-based interface for AWS DynamoDB
amazon-emailer1.8 0.0 amazonka VS amazon-emailerA simple daemon to process messages put into a postgresql table and mail them out using amazons SES.
minio-hs0.6 0.0 amazonka VS minio-hsMinio Client SDK for Haskell
Access the most powerful time series database as a service
Do you think we are missing an alternative of amazonka or a related project?
An Amazon Web Services SDK for Haskell with support for most public services. Parts of the code contained in this repository are auto-generated and automatically kept up to date with Amazon's latest service APIs.
- You can find the latest Haddock documentation for each respective library on the Amazonka website.
- A release changelog can be found in [lib/amazonka/CHANGELOG.md](lib/amazonka/CHANGELOG.md).
For problems, comments, or feedback please create an issue here on GitHub.
Amazonka is licensed under the Mozilla Public License Version 2.0.
The AWS service descriptions are licensed under Apache 2.0. Source files derived from the service descriptions contain an additional licensing clause in their header.
This repository is organised into the following directory structure:
lib/amazonka](lib/amazonka): The main library containing setup, authentication, and send logic. This will be your primary dependency.
lib/service/amazonka-*: A library per supported Amazon Web Service, you'll need to add a dependency on each selected service library.
amazonka-corelibrary upon which each of the services depends.
lib/amazonka-test](lib/amazonka-test): Common test functionality.
examples](examples): Basic examples for using the service libraries.
configs](configs): Service configuration, templates, and assets used by the code generator.
docs](docs): The website documentation and related build code.
gen](gen): The code and configuration generators.
nix](nix): Nix configuration code for toolchain packages.
scripts](scripts): Scripts to manage the project, such as the release lifecycle.
tools](tools): Custom bazel rules.
third_party](third_party): Third party packages and patches.
Supported Platforms and GHC Versions
8.10.7 are officially supported and tested on NixOS, Ubuntu, and macOS. GHC
8.6.5 may also work, but is not tested by our continuous integration pipeline.
This repository is built using a combination of Nix and your choice of Bazel or Cabal. If you're just using Amazonka as a git dependency in your Cabal or Stack project, you can skip these steps. But if you plan on contributing to the codebase - welcome, read on!
1. Clone this repository
git clone [email protected]:brendanhay/amazonka.git cd amazonka
2. Setup Nix
Building the code in this repository requires various development dependencies (e.g. Nix, Bazel, GHC.)
The Nix package manager is used to obtain and build the other dependencies in a hermetic environment. You can install Nix by following the official installation instructions:
sh <(curl -L https://nixos.org/nix/install) --daemon
Once Nix is setup, you can enable the cache to avoid building dependencies:
nix-env -iA cachix -f https://cachix.org/api/v1/install cachix use amazonka
3. Enter a Nix Shell
The build tools are installed and activated upon entering a Nix shell, which is achieved by running the following command in the root of the repository:
You can also enter a shell and explicitly specify the GHC version:
nix-shell --argstr ghcVersion 884
Optionally, if you have Direnv and lorri installed you can use the provided [.envrc](.envrc) instead, which will also add the [scripts](scripts) directory to your
PATH. You can extend this by adding your own uncommitted
.envrc.local file. See the Direnv Wiki for various recipes.
Building the Project
The following commands assume you're already in a nix-shell outlined in the previous step.
If you're familiar with Cabal, you can build
amazonka-* packages via:
cabal build amazonka amazonka-s3
Or the entire project (which will take a very long time!):
cabal build all
Alternatively, if you plan on contributing to the project or want to perform code generation, you will need to familiarise yourself with Bazel. You can build packages by specifying one or more targets using Bazel's label syntax:
bazel build //lib/amazonka //lib/services/amazonka-s3
Or build all Haskell libraries in the project using the
bazel build //lib/...
To view what targets are available in the workspace:
bazel query //...
By default, the
bazelcommand will use the same GHC version as the Nix shell's
ghcVersionargument. You can choose a different GHC version using
nix-shell --argstr ghcVersion 884- which is just a synonym for
bazel build --//tools/ghc:version=884.
Building the Documentation
The [docs](docs) Bazel package contains the Haddock target and Hugo static site definition and markdown content. To build the site locally, run:
bazel build //docs:bundle
Alternatively, you can serve the documentation site locally on
http://localhost:1313 by running:
bazel run //docs:serve
Running the Code Generator
The [gen](gen) Bazel package contains code generators for synthesising Haskell data types, packages, and configuration from the botocore service definitions.
[scripts/generate](scripts/generate) will run the code generator for all services configured in [config/services](config/services), for example:
Or, you can selectively run the generator on one or more services:
./scripts/generate ec2 s3 iam
To update the [botocore](botocore) service definitions used by the generator, you can run:
[scripts/generate-configs](scripts/generate-configs) will run the config generator to produce placeholder [config/serivces](config/services) configurations for the version of botocore pinned in the [WORKSPACE](WORKSPACE).
To generate any missing service configurations:
Service configurations generated in this way are intended as examples only and the resulting
configs/services/<name>.json:libraryName (Haskell package name) and
configs/annexes/<name>.json:serviceAbbreviation (Haskell package namespace) should be manually verified and curated as necessary.
For pull requests which affect generated output please do not include the regenerated
amazonka-* packages, only commit updates to the build rules, documentation, generator, and related configuration. This ensures the Continuous Integration process is the single source of truth for the generated code and reduces noise in pull requests, keeping them reviewable and focused on actual generator code/logic changes.
./scripts/format frequently - it's OK, I hate 2 spaces too, we're in this together.
Third Party Packages
When naming an additional library which provides supplemental functionality to
amazonka, if you want to use the
amazonka-* namespace, then please consider prefixing your package names with
amazonka-contrib-*. For example, amazonka-contrib-rds-utils.
This minimises potential future collisions with auto-generated package names and new AWS service and product releases.
*Note that all licence references and agreements mentioned in the amazonka README section above are relevant to that project's source code only.