aws-elastic-beanstalk-cli-setup: a self-contained installer for the EB CLI

An installer script, not the tool it installs

The repository description calls this a simplified EB CLI installation mechanism, and the README is more precise: it hosts scripts to generate self-contained installations of the EB CLI, where the EB CLI is the Elastic Beanstalk command line tool documented by AWS and published on PyPI as awsebcli.

So the code here is not the tool. The tool is a separate project. What is here is a script, ebcli_installer.py, whose job is to create a virtual environment, install awsebcli and its dependencies into it, and tell you how to put it on your PATH.

The word self-contained is the key. The script installs the awsebcli package in a virtual environment to prevent potential conflicts with other Python packages, and by default that environment lives in the standard .ebcli-virtual-env directory in the user's home directory. So the result is a directory tree containing a Python interpreter, the CLI and everything it needs, with the only interaction with the rest of the system being a PATH entry.

That is a narrow job, and the repository does it in a way that matches how infrastructure teams actually deploy tools. The tool itself is versioned independently on PyPI, and this repository is versioned separately with tags v0.2.0 from 2022-01-21 and v0.1.2 from 2019-05-23, plus a VERSION file at the root and the usual LICENSE, NOTICE, CONTRIBUTING.md and CODE_OF_CONDUCT.md.

The audience is whoever installs the CLI, which in practice is a provisioning pipeline or a base image build rather than a developer at a desk. The script's own list of prerequisites makes that clear: git, Python, and virtualenv, with pyenv recommended for the Python install and virtualenv's own documentation linked for the third.

The licence is Apache-2.0, with the LICENSE and NOTICE files at the root of the repository.

Three commands and a PATH instruction

The quick start is deliberately short, and the README numbers its steps.

Step one is cloning the repository, and the command is given verbatim:

git clone https://github.com/aws/aws-elastic-beanstalk-cli-setup.git

Step two is running the installer, and the command differs by platform. On MacOS and Linux, on Bash or Zsh:

python ./aws-elastic-beanstalk-cli-setup/scripts/ebcli_installer.py

On Windows, in PowerShell or a Command Prompt window:

python .\aws-elastic-beanstalk-cli-setup\scripts\ebcli_installer.py

Step three is the part that catches people. On Linux and macOS, the output contains instructions to add the EB CLI, and Python, executable file to the shell's $PATH variable, if it isn't already in it. The script prints the instructions rather than editing your shell profile, which is the right behaviour for an installer that might run in a pipeline, and it also means the PATH change is a deliberate step you perform rather than something that happens to you.

The Windows path has no equivalent step, and the reason is visible in the troubleshooting section, where the guidance is about the PowerShell execution policy rather than about PATH. If you hit the error about execution of scripts being disabled on this system, the fix is to set the execution policy to RemoteSigned and then rerun the bundled installer:

Set-ExecutionPolicy RemoteSigned

The README says the script can be executed with no arguments for most use cases, and that it is the way the tool is normally installed.

The advanced modes: pinned version, pinned Python, source, location

Four options turn the installer from a convenience into a provisioning tool, and they are the reason this repository exists in the AWS organisation rather than in someone's home directory.

The first pins the CLI version. The README gives the example of installing 3.14.13:

python scripts/ebcli_installer.py --version 3.14.13

The second pins the Python interpreter the CLI runs under, and the README is explicit that the Python version doesn't need to be in $PATH:

python scripts/ebcli_installer.py --python-installation /path/to/some/python/on/your/computer

That second option is the one that makes the tool usable in a controlled environment. A build image can ship exactly one Python build, put it wherever it likes, and have the EB CLI installed against that build without that build becoming the machine's default.

The third installs from source, and it accepts a Git repository or a .tar or .zip file:

python scripts/ebcli_installer.py --ebcli-source /path/to/awsebcli.zip

python scripts/ebcli_installer.py --ebcli-source /path/to/EBCLI/codebase/on/your/computer

The README describes this as useful when testing a development version of the EB CLI, which is a narrower and more practical motivation than it first appears, since a developer working on the CLI itself needs to run their own checkout rather than the published package.

The fourth moves the installation somewhere else, away from the default .ebcli-virtual-env directory in the home directory:

python scripts/ebcli_installer.py --location /path/to/ebcli/installation/location

Together these four options cover the four things a provisioning script has to control: what gets installed, what it runs on, where the code comes from and where the result lives.

The option list, and what quiet mode hides

The README prints the full option list, and reading it tells you what the script does and does not try to decide for you.

There is --virtualenv-executable, the path to the virtualenv installation to use to create the EBCLI's virtualenv. There is --hide-export-recommendation, a boolean to hide the recommendation to modify PATH, which exists because that recommendation is noise in some contexts. There is --location, the location to store the awsebcli packages and its dependencies in, and --python-installation, the path to the python installation under which to install the awsebcli and its dependencies. There is --quiet, to enable quiet mode to display only minimal, necessary output, and --ebcli-source, the filesystem path to a Git repository of the EBCLI, or a .zip or .tar file of the EBCLI source code.

And then --version, the version of EBCLI to install, which is a subtle detail worth flagging. In a script the flag named version is easy to mistake for the script's own version, and here it means the version of the CLI being installed, not the version of the installer. The script's own version is the VERSION file at the repository root, and the tags v0.2.0 and v0.1.2 are the script's releases.

The whole list is seven options, and there is no flag for anything else. There is no flag to install extra packages, no flag to skip the virtual environment, and no flag for proxy settings or indexes. That narrowness is a reasonable design choice for a script whose job is to produce one specific layout, and it also means that anything outside that layout is your own work.

Troubleshooting is mostly about missing headers and OpenSSL

The troubleshooting section is the longest part of the document after the FAQ, and it reveals a great deal about what actually goes wrong.

On Linux, the README says most installation problems have been due to missing libraries such as OpenSSL. On Ubuntu and Debian the fix is a single apt-get install of the build toolchain and the development headers:

apt-get install \
    build-essential zlib1g-dev libssl-dev libncurses-dev \
    libffi-dev libsqlite3-dev libreadline-dev libbz2-dev

On Amazon Linux and Fedora it is the equivalent in the RPM world, installing the Development Tools group and the matching -devel packages:

yum group install "Development Tools"
yum install \
    zlib-devel openssl-devel ncurses-devel libffi-devel \
    sqlite-devel.x86_64 readline-devel.x86_64 bzip2-devel.x86_64

On macOS the problem is described as being related to loading and linking OpenSSL and zlib, and the fix installs the libraries and then sets the compiler and linker flags to point at them:

brew install zlib openssl readline
CFLAGS="-I$(brew --prefix openssl)/include -I$(brew --prefix readline)/include -I$(xcrun --show-sdk-path)/usr/include" LDFLAGS="-L$(brew --prefix openssl)/lib -L$(brew --prefix readline)/lib -L$(brew --prefix zlib)/lib"

The README then says to run brew info to get the latest environment variable export suggestions, such as brew info zlib, which is a good practical habit because the Homebrew prefix moves between versions and a hardcoded path in an image build is a future failure.

The pattern across all three platforms is the same: the failures are about compiling native extensions against libraries that are present at runtime but missing their headers at build time. That is the direct consequence of the virtual environment approach, since a virtual environment inherits the system Python's ability to build C extensions, and that ability needs the toolchain and headers present. This is also the honest answer to the question the FAQ raises about whether dependency problems are solved by this mode of installation. The isolation helps with conflicts between Python packages. It does not help with a machine that cannot build an extension at all.

The questions the README asks of itself

The FAQ section is listed in the table of contents with five questions, and they are the most useful part of the document for anyone deciding whether this approach fits their environment.

The first asks, for the experienced Python developer, what's the advantage of this mode of installation instead of regular pip inside a virtualenv. The second asks whether on macOS, or Linux systems with brew, this is better than brew install awsebcli. The third asks whether you can still execute ebcli_installer.py if you already have the EB CLI installed. The fourth asks how ebcli_installer.py works. And the fifth asks whether there are dependency problems that this mode of installation doesn't solve.

The answers are not reproduced in the documentation this article is based on, so the questions themselves are the useful part, because they are the questions a sceptical reviewer would ask. The second one in particular is the right question to ask: a distribution package is simpler, and the case for this installer has to be about isolation and reproducibility rather than convenience. The fifth is the question that determines whether the tool is worth the trouble in your environment, and the troubleshooting section above is the honest answer to it.

The repository's own documentation is thorough in a way that is unusual for a two-file project, and the FAQ questions are a good sign of that, because the author has clearly thought about the objections rather than only about the happy path.

Licence, cadence and the size of the thing

The licence is Apache-2.0, with the LICENSE and NOTICE files at the root of the repository, which is the standard licence for AWS's own tooling repositories, though like any licence it does carry conditions such as keeping the licence and notice texts with distributions.

The maintenance picture needs stating by date rather than by adjective. The recent releases are v0.2.0 from 2022-01-21 and v0.1.2 from 2019-05-23, and the last push to the repository was on 2026-08-06. So the tree is being touched, and the published release is more than four years old, which for a script whose job is to install another tool is defensible, since the script only has to keep working with whatever awsebcli currently requires.

The size of the project is the other thing to note. The top level has the scripts directory, the VERSION file, the README, the licence and conduct files, and the GitHub configuration. There is no library, no service, no configuration format and no runtime dependency of its own beyond virtualenv.

So the honest summary is that this is a wrapper script with a very good README, which is exactly what a small provisioning helper should be. It does one thing, it does it in a way that keeps the tool and its dependencies away from the rest of the machine, and it documents the failure modes of that approach in enough detail that you can tell in advance whether the approach suits your environment. If your environment already has a working EB CLI, none of that matters and the package manager route is the right one. If you are deploying to machines you do not fully control, this is the version worth reading.

Editorial conclusion

Adopt this installer if you are rolling out the Elastic Beanstalk CLI to machines where a plain pip install would collide with existing Python packages, and you want one self-contained virtual environment holding the tool and its dependencies. Do not adopt it if a single user workstation already has the CLI working, since the official package manager route is simpler, and do not expect it to solve a broken Python toolchain, which the README's own troubleshooting section is largely about compiling dependencies rather than avoiding them. Verify first that your machines have git, Python and virtualenv available, since those are the stated prerequisites, that you can modify the PATH of the accounts that will run eb, because the installer prints instructions rather than editing your shell profile, and that the EB CLI version you pin is one you intend to support, since the script can install a specific version but the repository itself publishes only v0.2.0.

Frequently asked questions

Official sources

1. aws/aws-elastic-beanstalk-cli-setup on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases