This helps ensure that when a Docker image is built the expacted source
image is used regardless of what repository is configured as the
default on the host system. It also makes our Dockerfiles more
seamlessly convertible to using the GitHub Container Registry or any
other Open Container Initiative (OCI) compatible registry.

Use the full tag that includes the Alpine Linux version to ensure the
pulled image is always the same.

Use the full path for source container images

Instead of downloading the source archive, extracting it, and then
installing it with pip we instead just let pip directly install the
package.

Since we are now installing cisagov/skeleton-python-library directly
with pip we no longer need these OS packages.

Now that we are not overwriting the internal Python package file the
text we look for must match what is output by default. The Docker
Compose secret configuration is left in place to continue to serve as
an example and to be leveraged for a future update to
cisagov/skeleton-python-library that can provide similar functionality
to what was removed in this project.

…hon-library_directly

Install cisagov/skeleton-python-library directly with `pip`

We should not blindly upgrade all pre-installed packages. This can
create inconsistent build results due to changes in installed versions.

Pin the versions of the pip, setuptools, and wheel packages that are
installed.

We can move this instruction to the end of the Dockerfile now that we
are no longer working with files in the Docker container when building.

…eatable

Pin Python package versions and improve build repeatability

Instead of relying on `pip3` being on the PATH we instead call the
module through the Python executable. This ensures that the `pip` being
used is in the same environment as the `python3` being used.

Using a virtual environment is a Python best practice. We also
consolidate all of the Python dependency installation steps into a
single RUN instruction. This ensures that Python setup is cached in one
layer and mirrors the logical organization of this being a single step.

Since we cannot use long options on Alpine Linux we should explain what
the short options we are using do. I also changed the order of options
so that they are in alphabetical order.

Co-authored-by: Shane Frasier <[email protected]>

Use a Python virtual environment

This configuration includes a Pipfile configuration file and the
generated Pipfile.lock file that pins to specific versions for the
Python dependencies for this project. This will help us ensure
repeatable builds. The pipenv package is added as a developmental
requirement to support these files.

Now that we have a pipenv configuration we will use it to install the
Python dependencies for the image. The `build` workflow is updated to
no longer pass the VERSION build argument in line with this change.

Switch to using a multi-stage build in the Dockerfile. This reduces
image size since pipenv and its dependencices are not needed in the
final image. It also ensures that the system Python environment is
unmodified.

Install the core Python packages (pip, setuptools, and wheel) into the
system Python environment before installing pipenv. This keeps things
consistent with our usual approach to Python environments.

The comment references a command that is no longer being run.

Co-authored-by: Shane Frasier <[email protected]>

Co-authored-by: dav3r <[email protected]>

…tion

Install Python dependencies with `pipenv`

Change the tags used in the table to match the version of the project.
Previously "1.2.3" was used as an example version but there is no
reason not to use the real version of the image.

Update the README

Update the Dockerfile and testing to accommodate changes in the new
version.

Update dependencies

Co-authored-by: dav3r <[email protected]>