Pin subdependencies in CI

[cjolowicz]

trafficstars

~~For example, virtualenv which is used by Nox.~~ (virtualenv is now pinned.)

[cjolowicz]

So I guess the idea here would be to pip-compile the requirements file in .github/workflows/requirements.txt.

We recently switched to pipx in CI. There are now three environments:

• the Nox pipx environment (with nox-poetry and virtualenv)
• the Poetry pipx environment
• the global environment (with pip)

All use the same constraints file.

It would be sensible to use the official installer for Poetry instead.

If we compile the requirements for Nox and nox-poetry, we currently get a total of 14 dependencies for Python 3.10:

argcomplete==1.12.3
    # via nox
backports.entry-points-selectable==1.1.1
    # via virtualenv
colorlog==6.6.0
    # via nox
distlib==0.3.3
    # via virtualenv
filelock==3.4.0
    # via virtualenv
nox==2021.10.1
    # via
    #   -r /tmp/requirements.in
    #   nox-poetry
nox-poetry==0.9.0
    # via -r /tmp/requirements.in
packaging==21.3
    # via
    #   nox
    #   nox-poetry
platformdirs==2.4.0
    # via virtualenv
py==1.11.0
    # via nox
pyparsing==3.0.6
    # via packaging
six==1.16.0
    # via virtualenv
tomlkit==0.7.2
    # via nox-poetry
virtualenv==20.10.0
    # via nox

That's still kind of manageable, I guess.

We recently had CI breakage because of unpinned subdependencies, when the latest pyparsing releases weren't compatible with packaging. The situation was made worse because Poetry prevented us from upgrading packaging. That prompted the move to pipx, to isolate Poetry and Nox.

[cjolowicz]

On a related note, we don't enable Dependabot PRs for indirect dependencies in poetry.lock. It's a tradeoff between the churn of upgrading a large number of dependencies separately, and the risk of having outdated and possibly vulnerable dependencies. The instance repository now has Dependabot upgrades for indirect dependencies, so projects are generated with (reasonably) recent dependency versions.