Skip to content

Use hatchling instead of setuptools #794

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 4 commits into from
Mar 29, 2025
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 4 additions & 1 deletion .github/workflows/tox.yml
Original file line number Diff line number Diff line change
Expand Up @@ -24,7 +24,7 @@ jobs:
strategy:
fail-fast: false
matrix:
python-version: ["3.9", "3.10", "3.11"]
python-version: ["3.9", "3.10", "3.11", "3.12", "3.13"]
steps:
- uses: actions/checkout@v4
- name: Set up Python ${{ matrix.python-version }}
Expand All @@ -38,6 +38,9 @@ jobs:
- name: Run tox -e lint
run: |
tox -e lint
- name: Run tox -e mypy
run: |
tox -e mypy
build:
runs-on: ubuntu-latest
strategy:
Expand Down
11 changes: 0 additions & 11 deletions .pre-commit-config.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -37,14 +37,3 @@ repos:
entry: ruff format --check --diff
language: system
types: [python]
- repo: https://github.com/pre-commit/mirrors-mypy
rev: v1.4.1
hooks:
- id: mypy
# empty args needed in order to match mypy cli behavior
additional_dependencies:
- types-paramiko
- types-setuptools
- setuptools-scm
- alabaster
- pytest
7 changes: 5 additions & 2 deletions .readthedocs.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,10 @@ version: 2
build:
os: ubuntu-22.04
tools:
python: "3.9"
python: "3.11"
python:
install:
- requirements: dev-requirements.txt
- method: pip
path: .
extra_requirements:
- doc
21 changes: 0 additions & 21 deletions MANIFEST.in

This file was deleted.

2 changes: 1 addition & 1 deletion README.rst
Original file line number Diff line number Diff line change
Expand Up @@ -59,7 +59,7 @@ Write your first tests file to `test_myinfra.py`:

And run it::

$ py.test -v test_myinfra.py
$ pytest -v test_myinfra.py


====================== test session starts ======================
Expand Down
3 changes: 0 additions & 3 deletions dev-requirements.txt

This file was deleted.

58 changes: 29 additions & 29 deletions doc/source/backends.rst
Original file line number Diff line number Diff line change
Expand Up @@ -77,7 +77,7 @@ This is the default backend when no hosts are provided (either via
``--hosts`` or in modules). Commands are run locally in a subprocess under
the current user::

$ py.test --sudo test_myinfra.py
$ pytest --sudo test_myinfra.py


paramiko
Expand All @@ -91,7 +91,7 @@ able to connect without password (using passwordless keys or using

You can provide an alternate ssh-config::

$ py.test --ssh-config=/path/to/ssh_config --hosts=server
$ pytest --ssh-config=/path/to/ssh_config --hosts=server


docker
Expand All @@ -100,7 +100,7 @@ docker
The Docker backend can be used to test *running* Docker containers. It uses the
`docker exec <https://docs.docker.com/reference/commandline/exec/>`_ command::

$ py.test --hosts='docker://[user@]container_id_or_name'
$ pytest --hosts='docker://[user@]container_id_or_name'

See also the :ref:`Test docker images` example.

Expand All @@ -111,19 +111,19 @@ podman
The Podman backend can be used to test *running* Podman containers. It uses the
`podman exec <https://github.com/containers/libpod/blob/master/docs/source/markdown/podman.1.md>`_ command::

$ py.test --hosts='podman://[user@]container_id_or_name'
$ pytest --hosts='podman://[user@]container_id_or_name'


ssh
~~~

This is a pure SSH backend using the ``ssh`` command. Example::

$ py.test --hosts='ssh://server'
$ py.test --ssh-config=/path/to/ssh_config --hosts='ssh://server'
$ py.test --ssh-identity-file=/path/to/key --hosts='ssh://server'
$ py.test --hosts='ssh://server?timeout=60&controlpersist=120'
$ py.test --hosts='ssh://server' --ssh-extra-args='-o StrictHostKeyChecking=no'
$ pytest --hosts='ssh://server'
$ pytest --ssh-config=/path/to/ssh_config --hosts='ssh://server'
$ pytest --ssh-identity-file=/path/to/key --hosts='ssh://server'
$ pytest --hosts='ssh://server?timeout=60&controlpersist=120'
$ pytest --hosts='ssh://server' --ssh-extra-args='-o StrictHostKeyChecking=no'

By default timeout is set to 10 seconds and ControlPersist is set to 60 seconds.
You can disable persistent connection by passing `controlpersist=0` to the options.
Expand All @@ -135,10 +135,10 @@ salt
The salt backend uses the `salt Python client API
<https://docs.saltstack.com/en/latest/ref/clients/>`_ and can be used from the salt-master server::

$ py.test --hosts='salt://*'
$ py.test --hosts='salt://minion1,salt://minion2'
$ py.test --hosts='salt://web*'
$ py.test --hosts='salt://G@os:Debian'
$ pytest --hosts='salt://*'
$ pytest --hosts='salt://minion1,salt://minion2'
$ pytest --hosts='salt://web*'
$ pytest --hosts='salt://G@os:Debian'

Testinfra will use the salt connection channel to run commands.

Expand All @@ -156,9 +156,9 @@ and how to connect them, using Testinfra's Ansible backend.

To use the Ansible backend, prefix the ``--hosts`` option with ``ansible://`` e.g::

$ py.test --hosts='ansible://all' # tests all inventory hosts
$ py.test --hosts='ansible://host1,ansible://host2'
$ py.test --hosts='ansible://web*'
$ pytest --hosts='ansible://all' # tests all inventory hosts
$ pytest --hosts='ansible://host1,ansible://host2'
$ pytest --hosts='ansible://web*'

An inventory may be specified with the ``--ansible-inventory`` option, otherwise
the default (``/etc/ansible/hosts``) is used.
Expand All @@ -169,8 +169,8 @@ are supported values. Other connections (or if you are using the ``--force-ansib
option) will result in testinfra running all commands via Ansible itself,
which is substantially slower than the other backends::

$ py.test --force-ansible --hosts='ansible://all'
$ py.test --hosts='ansible://host?force_ansible=True'
$ pytest --force-ansible --hosts='ansible://all'
$ pytest --hosts='ansible://host?force_ansible=True'

By default, the Ansible connection backend will first try to use
``ansible_ssh_private_key_file`` and ``ansible_private_key_file`` to authenticate,
Expand Down Expand Up @@ -203,14 +203,14 @@ support connecting to a given container name within a pod and using a given
namespace::

# will use the default namespace and default container
$ py.test --hosts='kubectl://mypod-a1b2c3'
$ pytest --hosts='kubectl://mypod-a1b2c3'
# specify container name and namespace
$ py.test --hosts='kubectl://somepod-2536ab?container=nginx&namespace=web'
$ pytest --hosts='kubectl://somepod-2536ab?container=nginx&namespace=web'
# specify the kubeconfig context to use
$ py.test --hosts='kubectl://somepod-2536ab?context=k8s-cluster-a&container=nginx'
$ pytest --hosts='kubectl://somepod-2536ab?context=k8s-cluster-a&container=nginx'
# you can specify kubeconfig either from KUBECONFIG environment variable
# or when working with multiple configuration with the "kubeconfig" option
$ py.test --hosts='kubectl://somepod-123?kubeconfig=/path/kubeconfig,kubectl://otherpod-123?kubeconfig=/other/kubeconfig'
$ pytest --hosts='kubectl://somepod-123?kubeconfig=/path/kubeconfig,kubectl://otherpod-123?kubeconfig=/other/kubeconfig'

openshift
~~~~~~~~~
Expand All @@ -221,30 +221,30 @@ support connecting to a given container name within a pod and using a given
namespace::

# will use the default namespace and default container
$ py.test --hosts='openshift://mypod-a1b2c3'
$ pytest --hosts='openshift://mypod-a1b2c3'
# specify container name and namespace
$ py.test --hosts='openshift://somepod-2536ab?container=nginx&namespace=web'
$ pytest --hosts='openshift://somepod-2536ab?container=nginx&namespace=web'
# you can specify kubeconfig either from KUBECONFIG environment variable
# or when working with multiple configuration with the "kubeconfig" option
$ py.test --hosts='openshift://somepod-123?kubeconfig=/path/kubeconfig,openshift://otherpod-123?kubeconfig=/other/kubeconfig'
$ pytest --hosts='openshift://somepod-123?kubeconfig=/path/kubeconfig,openshift://otherpod-123?kubeconfig=/other/kubeconfig'

winrm
~~~~~

The winrm backend uses `pywinrm <https://pypi.python.org/pypi/pywinrm>`_::

$ py.test --hosts='winrm://Administrator:Password@127.0.0.1'
$ py.test --hosts='winrm://vagrant@127.0.0.1:2200?no_ssl=true&no_verify_ssl=true'
$ pytest --hosts='winrm://Administrator:Password@127.0.0.1'
$ pytest --hosts='winrm://vagrant@127.0.0.1:2200?no_ssl=true&no_verify_ssl=true'

pywinrm's default read and operation timeout can be overridden using query
arguments ``read_timeout_sec`` and ``operation_timeout_sec``::

$ py.test --hosts='winrm://vagrant@127.0.0.1:2200?read_timeout_sec=120&operation_timeout_sec=100'
$ pytest --hosts='winrm://vagrant@127.0.0.1:2200?read_timeout_sec=120&operation_timeout_sec=100'

LXC/LXD
~~~~~~~

The LXC backend can be used to test *running* LXC or LXD containers. It uses the
`lxc exec <https://linuxcontainers.org/lxd/getting-started-cli/>`_ command::

$ py.test --hosts='lxc://container_name'
$ pytest --hosts='lxc://container_name'
11 changes: 2 additions & 9 deletions doc/source/conf.py
Original file line number Diff line number Diff line change
Expand Up @@ -22,8 +22,8 @@
# serve to show the default.

import datetime
import importlib.metadata
import os
import subprocess
import sys

import alabaster
Expand Down Expand Up @@ -68,14 +68,7 @@
# built documents.
#
# The short X.Y version.
version = (
subprocess.check_output(
["python3", "setup.py", "--version"],
cwd=os.path.join(os.path.dirname(__file__), os.pardir, os.pardir),
)
.decode()
.strip()
)
version = importlib.metadata.version("pytest-testinfra")
# The full version, including alpha/beta/rc tags.
release = version

Expand Down
12 changes: 6 additions & 6 deletions doc/source/examples.rst
Original file line number Diff line number Diff line change
Expand Up @@ -18,7 +18,7 @@ Pytest support `test parametrization <https://pytest.org/latest/parametrize.html


# GOOD: Each package is tested
# $ py.test -v test.py
# $ pytest -v test.py
# [...]
# test.py::test_package[local-nginx-1.6] PASSED
# test.py::test_package[local-python-2.7] PASSED
Expand Down Expand Up @@ -86,7 +86,7 @@ When your Vagrant machine is up and running, you can easily run your testinfra
test suite on it::

vagrant ssh-config > .vagrant/ssh-config
py.test --hosts=default --ssh-config=.vagrant/ssh-config tests.py
pytest --hosts=default --ssh-config=.vagrant/ssh-config tests.py


Integration with Jenkins
Expand All @@ -101,7 +101,7 @@ If your Jenkins slave can run Vagrant, your build scripts can be like::
pip install pytest-testinfra paramiko
vagrant up
vagrant ssh-config > .vagrant/ssh-config
py.test --hosts=default --ssh-config=.vagrant/ssh-config --junit-xml junit.xml tests.py
pytest --hosts=default --ssh-config=.vagrant/ssh-config --junit-xml junit.xml tests.py


Then configure Jenkins to get tests results from the `junit.xml` file.
Expand All @@ -117,12 +117,12 @@ This kind of tests are close to monitoring checks, so let's push them to
The Testinfra option `--nagios` enables a behavior compatible with a nagios plugin::


$ py.test -qq --nagios --tb line test_ok.py; echo $?
$ pytest -qq --nagios --tb line test_ok.py; echo $?
TESTINFRA OK - 2 passed, 0 failed, 0 skipped in 2.30 seconds
..
0

$ py.test -qq --nagios --tb line test_fail.py; echo $?
$ pytest -qq --nagios --tb line test_fail.py; echo $?
TESTINFRA CRITICAL - 1 passed, 1 failed, 0 skipped in 2.24 seconds
.F
/usr/lib/python3/dist-packages/example/example.py:95: error: [Errno 111] error msg
Expand All @@ -142,7 +142,7 @@ additionally (on your host machine, not in the VM handled by kitchen) ::

verifier:
name: shell
command: py.test --hosts="paramiko://${KITCHEN_USERNAME}@${KITCHEN_HOSTNAME}:${KITCHEN_PORT}?ssh_identity_file=${KITCHEN_SSH_KEY}" --junit-xml "junit-${KITCHEN_INSTANCE}.xml" "test/integration/${KITCHEN_SUITE}"
command: pytest --hosts="paramiko://${KITCHEN_USERNAME}@${KITCHEN_HOSTNAME}:${KITCHEN_PORT}?ssh_identity_file=${KITCHEN_SSH_KEY}" --junit-xml "junit-${KITCHEN_INSTANCE}.xml" "test/integration/${KITCHEN_SUITE}"


.. _test docker images:
Expand Down
8 changes: 4 additions & 4 deletions doc/source/invocation.rst
Original file line number Diff line number Diff line change
Expand Up @@ -10,7 +10,7 @@ test remotes systems using `paramiko <https://www.paramiko.org>`_ (a
ssh implementation in python)::

$ pip install paramiko
$ py.test -v --hosts=localhost,root@webserver:2222 test_myinfra.py
$ pytest -v --hosts=localhost,root@webserver:2222 test_myinfra.py

====================== test session starts ======================
platform linux -- Python 2.7.3 -- py-1.4.26 -- pytest-2.6.4
Expand Down Expand Up @@ -45,7 +45,7 @@ If you have a lot of tests, you can use the pytest-xdist_ plugin to run tests us
$ pip install pytest-xdist

# Launch tests using 3 processes
$ py.test -n 3 -v --host=web1,web2,web3,web4,web5,web6 test_myinfra.py
$ pytest -n 3 -v --host=web1,web2,web3,web4,web5,web6 test_myinfra.py


Advanced invocation
Expand All @@ -54,10 +54,10 @@ Advanced invocation
::

# Test recursively all test files (starting with `test_`) in current directory
$ py.test
$ pytest

# Filter function/hosts with pytest -k option
$ py.test --hosts=webserver,dnsserver -k webserver -k nginx
$ pytest --hosts=webserver,dnsserver -k webserver -k nginx


For more usages and features, see the Pytest_ documentation.
Expand Down
8 changes: 8 additions & 0 deletions hatch.toml
Original file line number Diff line number Diff line change
@@ -0,0 +1,8 @@
[version]
source = "vcs"

[build.targets.sdist]
packages = ["testinfra"]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hatch doesn't use file finders like setuptools

Explicit include is needed


[build.targets.wheel]
packages = ["testinfra"]
Loading