[FR] Additional dependency pins?

So there’s one thing that’s been bothering me for some time: the inability to have consistently reproducible linter envs. When I add a hook for flake8, I normally also specify some plugins via additional_dependencies but then, if any of those plugins or their transitive deps change, there’s a chance that the linters will suddenly start failing for no obvious reason when there’s no changes to the project. I don’t like pinning those plugin versions because (1) there’s no tooling to autobump them specifically and (2) even if the direct deps are pinned, the indirect ones aren’t which assumes a level of fragility. I suppose this could be solved with the PIP_CONSTRAINTS env var but it would be nice to have some mechanism that would translate into pre-commit running pip install -r requirements.txt -c constraints.txt. Ideas?

[webknjaz]

Oh, that is not what I want: I need the whole deptree pinned which shouldn’t be a manual effort + it feels wrong to put tens of indirect deps in this config file.

[asottile]

@ssbarnea I don’t appreciate you dogpiling on every single issue about this – I’ve heard your opinion but you don’t understand the technical parts of this and I’ve already requested you to stop

but I’m glad you brought up tox because it serves as a perfect example of why this isn’t feasible

even a trivial run of tox adds 1.6s to the execution, an unacceptable startup time for pre-commit:

$ time tox4 -e wat
.pkg: get_requires_for_build_wheel> python /tmp/y/astpretty/venv/lib/python3.8/site-packages/tox/util/pep517/backend.py True setuptools.build_meta __legacy__
.pkg: prepare_metadata_for_build_wheel> python /tmp/y/astpretty/venv/lib/python3.8/site-packages/tox/util/pep517/backend.py True setuptools.build_meta __legacy__
.pkg: get_requires_for_build_sdist> python /tmp/y/astpretty/venv/lib/python3.8/site-packages/tox/util/pep517/backend.py True setuptools.build_meta __legacy__
.pkg: build_sdist> python /tmp/y/astpretty/venv/lib/python3.8/site-packages/tox/util/pep517/backend.py True setuptools.build_meta __legacy__
wat: install_package> python -I -m pip install --no-deps --force-reinstall /tmp/y/astpretty/.tox/4/.pkg/dist/astpretty-2.1.0.tar.gz
wat: commands[0]> python -c 'print("hello world")'
hello world
.pkg: _exit> python /tmp/y/astpretty/venv/lib/python3.8/site-packages/tox/util/pep517/backend.py True setuptools.build_meta __legacy__
  wat: OK (1.38=setup[1.35]+cmd[0.03] seconds)
  congratulations :) (1.41 seconds)

real	0m1.613s
user	0m1.487s
sys	0m0.128s

this is because it has to ensure things are at a consistent state (and that costs a lot! it essentially has to rerun all of the build and installation) – this is what would be necessary at all to have a working environment

and then you look at tox3, which doesn’t even know that the cache changes when requirements change (in a way tox4 still doesn’t in all cases (recursive deps, constraints, environment variables) as it’s only solved for the basic, common cases) – requiring -r all the time. I’m not going to build a solution which is incorrect and broken in the common case.

and that doesn’t even bring us to the cache problem, pre-commit needs to know up front whether one of its immutable environments is satisfied already, otherwise it must run extremely slow build commands every time. consider just if you specified . as a dependency – it must then index every file in your codebase and rebuild essentially every time you make a change. really not a desirable behaviour. consider if you specified -r, you’d have to have a very-specific pip-option-sensitive parser to read and recurse that. consider if you specified a package.json – now pre-commit needs to understand the nuances of npm dependency management. consider cargo.toml, etc. etc.

so this is your final warning, please do not comment about this again or I will have no other choice but to prevent you from contributing. I’m sorry it has come to this but I’m tired of your behaviour on this topic.