Install it, and prove the installation is sound

Install, per operating system

Three supported platforms, and the instructions are equivalent on all three. The first two commands install pipx, which most systems do not ship.

Windows

Python 3.11 or later, from python.org. Then, in PowerShell:

py -m pip install --user pipx
py -m pipx ensurepath

Open a new PowerShell window, then:

pipx install m365-governance-as-code==1.0.0b6
m365-governance doctor

macOS

brew install pipx
pipx ensurepath

Open a new terminal, then:

pipx install m365-governance-as-code==1.0.0b6
m365-governance doctor

Linux

Install pipx with your distribution's package manager, then:

pipx ensurepath

Open a new shell, then:

pipx install m365-governance-as-code==1.0.0b6
m365-governance doctor

The package is named pipx almost everywhere, and python-pipx on Arch:

Where your distribution has no package, pipx's own documentation gives:

python3 -m pip install --user pipx
python3 -m pipx ensurepath

That path fails with externally-managed-environment on a distribution that enforces PEP 668, which is the same set that ships the package, so the two cover each other.

Verify

m365-governance doctor
m365-governance --version

Expected: doctor exits 0 and reports the installed content, and the version is 1.0.0b6.

Why the new shell is not optional

pipx ensurepath edits your shell profile, and a shell that is already open never reads it again. Skip the new window and you get:

command not found: m365-governance

after an installation that succeeded, which reads like a broken package. pipx gives each application a directory of its own, and that directory is not on your PATH until ensurepath puts it there.

Why pipx and not pip

This is a command-line application rather than a library you import, and a modern Python refuses to install one into the system environment:

error: externally-managed-environment

That is PEP 668, and Homebrew's Python, Debian's and Ubuntu's all enforce it. pipx gives the application an environment of its own and puts the command on your PATH, which is what you wanted from pip install anyway.

The same rule applies to installing pipx itself, which is why the Linux instructions reach for the distribution's package first. Windows does not enforce PEP 668 on the python.org build, so py -m pip install --user pipx is the documented path there.

Python 3.11 or later. Two dependencies. Nothing else is needed to run the engine, the rules or the tests, because they all run offline against fixtures.

Or a virtual environment, which needs nothing else

If you would rather manage the environment yourself, or you are putting this on a build agent where a PATH change is unwelcome:

python3 -m venv .venv
./.venv/bin/pip install m365-governance-as-code==1.0.0b6
./.venv/bin/m365-governance doctor

Nothing is added to your PATH, and the commands below all work with the ./.venv/bin/ prefix.

The version

The == is not optional yet. 1.0.0b6 is a pre-release under PEP 440, and pip skips pre-releases unless a version is pinned or --pre is given. Plain pipx install m365-governance-as-code resolves to nothing until there is a stable release, so the pin is the command rather than a precaution.

Requirements

The split matters when you are deciding what to put on a build agent. An agent that evaluates evidence somebody else collected needs Python and nothing more.

Everything ships inside the package

The rules, the profiles, the schemas and the collector are packaged. An installed copy works from any directory, and nothing resolves against a checkout.

That is a design commitment rather than a convenience. A clean installation is the reference environment, so a rule set that works in a working copy and fails for a user is a packaging defect and not a user error.

Prove it before you use it

m365-governance doctor

m365-governance doctor    reading content from: the installed package

Environment
  ok    python                   3.14.6 (needs 3.11 or later)
  ok    m365-governance          1.0.0b6
  ok    platform                 Darwin arm64

Read the first line before the checks. It says which content is being read: the installed package, or a directory you pointed it at with --root. That one line separates a real installation problem from a checkout that was never packaged.

doctor exits 1 when something is wrong, and prints the report either way.

Working on the project instead of using it

pip install -e . && pip install -r requirements-dev.txt

Where the example evidence lives

Example evidence ships inside the package. doctor confirms it is there, in the packaged content line, but it does not print the path. This does:

python -c "import m365_governance, pathlib; print(pathlib.Path(m365_governance.__file__).parent / 'data' / 'fixtures')"

Everything in your first assessment runs against those files, with no tenant.