salt/requirements/static
2019-05-08 13:16:26 +01:00
..
py2 Previously generated requirements were py2 only 2019-05-08 13:16:26 +01:00
arch.in Kubernetes 3.0.0 does include the requirements files. pip-compile chokes on that 2019-05-08 13:16:26 +01:00
centos-6.in Kubernetes 3.0.0 does include the requirements files. pip-compile chokes on that 2019-05-08 13:16:26 +01:00
centos-7.in Kubernetes 3.0.0 does include the requirements files. pip-compile chokes on that 2019-05-08 13:16:26 +01:00
debian-8.in Kubernetes 3.0.0 does include the requirements files. pip-compile chokes on that 2019-05-08 13:16:26 +01:00
debian-9.in Kubernetes 3.0.0 does include the requirements files. pip-compile chokes on that 2019-05-08 13:16:26 +01:00
fedora-28.in Kubernetes 3.0.0 does include the requirements files. pip-compile chokes on that 2019-05-08 13:16:26 +01:00
fedora-29.in Kubernetes 3.0.0 does include the requirements files. pip-compile chokes on that 2019-05-08 13:16:26 +01:00
opensuse-42.in Kubernetes 3.0.0 does include the requirements files. pip-compile chokes on that 2019-05-08 13:16:26 +01:00
opensuse-leap-15.in Kubernetes 3.0.0 does include the requirements files. pip-compile chokes on that 2019-05-08 13:16:26 +01:00
README.rst Start handling static(and platform specific) requirements files 2019-03-15 11:16:35 +00:00
ubuntu-14.04.in Kubernetes 3.0.0 does include the requirements files. pip-compile chokes on that 2019-05-08 13:16:26 +01:00
ubuntu-16.04.in Kubernetes 3.0.0 does include the requirements files. pip-compile chokes on that 2019-05-08 13:16:26 +01:00
ubuntu-18.04.in Kubernetes 3.0.0 does include the requirements files. pip-compile chokes on that 2019-05-08 13:16:26 +01:00
windows.in Don't lock the docker requirement. It's not locked on the other platforms 2019-05-08 13:16:26 +01:00

What Is This All About
======================

This directory will contain platform specific requirements(and the requirements
of each requirements) locked to the versions used as if the testing environment
was setup using the salt-jenkins states.

The purpose of this is to ease the transition to `nox` and golden images where
only binary system packages are installed on the golden image and `nox`
installs the python dependencies on virtualenv specifically created for the
test run.

This will also make sure we run the tests with the exact same dependencies
everytime.