Replace tox.ini and Makefile for noxfile.py

[slimreaper35]

https://nox.thea.codes/en/stable

Notes

• Each session is defined as a Python function with the @nox.session decorator
• reuse_venv=True is used to speed up the execution of sessions by reusing the existing venv
• Docstrings below each session function are used as session descriptions in the help output
• The module docstring is used in the help output when running nox -l, --list too
• The *session.posargs is used to pass additional arguments to the command
• The silent=True argument is used to suppress the output of the command only if the command was successful
• To use external commands, set the external=True argument in the session.run() method
  (it should work without the external=True argument, but it's better to be explicit and silence the warning)
• The only command from Makefile that is not included here is make venv
  (it probably doesn't make sense to have a session for that, it would require contributors to install nox first)
• I made some minor adjustments to pytest commands to make them more readable and clean

---

Maintainers will complete the following section

• Commit messages are descriptive enough
• Code coverage from testing does not decrease and new code is covered
• Docs updated (if applicable)
• Docs links in the code are still valid (if docs were updated)

Note: if the contribution is external (not from an organization member), the CI
pipeline will not run automatically. After verifying that the CI is safe to run:

• approve GitHub Actions workflows by clicking a button
• approve the Red Hat Trusted App Pipeline container build by commenting /ok-to-test
  (as is the standard for Pipelines as Code)

[eskultety]

@slimreaper35 this is a very shallow top-level review I've done without trying it locally myself, but from the first look it looks fine, definitely doesn't hinder readability when compared to the declarative tox.ini config, so from that POV seems like a solid alternative to what we have today.

[a-ovchinnikov]

This looks so neat!

[a-ovchinnikov]

A couple small questions, but LGTM overall.

[a-ovchinnikov]

Obligatory [non-blocking] tag.

Would this be too much of generalization?

@nox.session()
def mypy(session: Session) -> None:
    """Run mypy on cachi2 and tests directories"""
    run_cmd_for(session, "mypy --install-types --non-interactive cachi2 tests")

def run_cmd_for(session, cmd, loud=False):
    install_requirements(session)
    session.run(*cmd.split(), *session.posargs, silent=not loud)

[slimreaper35]

I don't know, to me it feels like an unnecessary wrapper around each command.

[ben-alkov]

Given that all of the commands are exactly the same, maintainability would be increased by

def run_cmd(cmd, session):
	install_requirements(session)
    session.run(*cmd.split(), *session.posargs, silent=True)

called from the individual sessions as run_cmd(cmd, session).

Why? I realize that it seems excessive, but:

• It actually reduces the amount of repetition. If we need to change the options to session.run, we can do it in ONE place instead of ten
• If we do have one specific session which needs to have a slightly different session.run, we can call session.run directly from that specific session, i.e. ignoring our "wrapper". As it stands, if one out the many sessions has different options, it's really hard to see.

[ben-alkov]

clean:
	rm -rf dist venv .tox *.egg-info *.log*

mock-unittest-data:
	hack/mock-unittest-data/gomod.sh

I'm not advocating for keeping these, but they must be documented somewhere. I can't even remember the complete list of what "clean" takes care of, much less how to refresh the mock data 😆 ...

[slimreaper35]

I'm not advocating for keeping these, but they must be documented somewhere. I can't even remember the complete list of what "clean" takes care of, much less how to refresh the mock data 😆 ...

I've never used hack/mock-unittest-data/gomod.sh or hack/mock-unittest-data/yarn.py

[ben-alkov]

I'm not advocating for keeping these, but they must be documented somewhere. I can't even remember the complete list of what "clean" takes care of, much less how to refresh the mock data 😆 ...

I've never used hack/mock-unittest-data/gomod.sh or hack/mock-unittest-data/yarn.py

All the more reason to document them, before the last person who actually did run them gets hit by a bus 😁

[eskultety]

What I'm missing in this PR:

• adding .nox to .gitignore
• making the final switch to nox from tox/Makefile, i.e. dropping latter
• docs changes

[brunoapimentel]

This LGTM, it only needs the changes that Erik pointed out.

With these changes, the only reason to create a venv outside of .nox is to run the cachi2 command itself? I'm wondering if we need to keep the make venv command at all. It seems to me that the best approach is to install nox as a system-wide package, so we can probably move the creation of the cachi2 venv to nox.

[eskultety]

This LGTM, it only needs the changes that Erik pointed out.

With these changes, the only reason to create a venv outside of .nox is to run the cachi2 command itself? I'm wondering if we need to keep the make venv command at all. It seems to me that the best approach is to install nox as a system-wide package, so we can probably move the creation of the cachi2 venv to nox.

How about just documenting it? ;) Having a shortcut command for python3 -m venv venv; venv/bin/pip install -r requirements.txt -r requirements-extras.txt seems suspicious, I was never a fan of that, but went with the flow since we had the Makefile and some Makefile targets depended on having a venv, otherwise I'd have deleted it already a while ago, but now we have a chance to get rid of any cruft we don't need and given nox/tox default to creating venvs for all jobs I say it's time to say goodbye to holding hands when it comes to venv creation, it's a standard mechanism anyway :) .

[eskultety]

unrelated change

[eskultety]

unrelated change

[eskultety]

unrelated change