his article shows how to install Python 3, pip, venv, virtualenv, and pipenv on Red Hat Enterprise Linux 7. After following the steps in this article, you should be in a good position to follow many Python guides and tutorials using RHEL. Note: For RHEL 8 installs, See Python on RHEL 8.

Using Python virtual environments is a best practice to isolate project-specific dependencies and create reproducible environments. Other tips and FAQs for working with Python and software collections on RHEL 7 are also covered.

There are a number of different ways to get Python 3 installed on RHEL. This article uses Red Hat Software Collections because these give you a current Python installation that is built and supported by Red Hat. During development, support might not seem that important to you. However, support is important to those who have to deploy and operate the applications you write. To understand why this is important, consider what happens when your application is in production and a critical security vulnerability in a core library (for example SSL/TLS) is discovered. This type of scenario is why many enterprises use Red Hat.

Python 3.6 is used in this article. It was the most recent, stable release when this was written. However, you should be able to use these instructions for any of the versions of Python in Red Hat Software Collections including 2.7, 3.4, 3.5, and future collections such as 3.7.

Using Ansible content that depends on non-default dependencies can be tricky. Packages must be installed on each node, play nicely with other software installed on the host system, and be kept in sync.

To help simplify this process, we have introduced the concept of Execution Environments, which you can create with Ansible Builder.

Hello and welcome to another introductory Ansible blog post, where we'll be covering a new command-line interface (CLI) tool, Ansible Builder. Please note that this article will cover some intermediate-level topics such as containers (Ansible Builder uses Podman by default), virtual environments, and Ansible Content Collections. If you have some familiarity with those topics, then read on to find out what Ansible Builder is, why it was developed, and how to use it. 

This project is currently in development upstream on GitHub and is not yet part of the Red Hat Ansible Automation Platform product.  As with all Red Hat software, our code is open and we have an open source development model for our enterprise software.  The goal of this blog post is to show the current status of this initiative, and start getting the community and customers comfortable with our methodologies, thought process, and concept of Execution Environments.  Feedback on this upstream project can be provided on GitHub via comments and issues, or provided via the various methods listed on our website.  There is also a great talk on AnsibleFest.com, titled “Creating and Using Ansible Execution Environments,” available on-demand, which can provide additional clarification.

Ansible Builder is a tool that automates the process of building execution environments using the schemas and tooling defined in various Ansible Collections and by the user.

s part of a Red Hat Ansible Automation Platform subscription, customers have access to supported versions of on-premise packages, as well as hosted services provided on console.redhat.com. Red Hat provides a published product life cycle for Ansible Automation Platform so that customers and partners can properly plan, deploy, support, and maintain their on-premise automation clusters as well as hosted services that they use as part of the Ansible Automation Platform subscription.

This life cycle encompasses stated time periods for each version of Ansible Automation Platform, which is a logical grouping of many individual product components. The life cycle for each version of Ansible Automation Platform is split into production phases, each identifying the various levels of maintenance over a period of time from the initial release date. While multiple versions of Ansible Automation Platform may be supported at any one time, note that this life cycle applies to each specific version of Ansible Automation Platform and does not apply to (for example) the 1.x or 2.x major version as a whole. That is, semantic versioning rules are not used as part of Ansible Automation Platform releases (but specific contained components may).

Customers are expected to upgrade their Ansible Automation Platform environments to the most current supported version of the product in a timely fashion. Features and bug fixes target only the latest versions of the product, though some allowance may be given for high security risk items.