What's the problem this feature will solve?

Packages listed in constraints files need to evolve too. Unfortunately, if the constraints file used lists the package under development, pip will complain that the package you are installing conflicts with the constraint for that package.

You can work around this when using requirements.txt files and passing these to deps, since these dependencies are installed before the package and the -c lines only apply when installing these dependencies, but there does not appear to be an easy way to do this when using the PEP-517 hotness and defining all your dependencies in pyproject.toml files. This is preventing OpenStack (and presumably others users of constraints files) from migrating entirely to pyproject.toml files.

Describe the solution you'd like

I would like the current package-under-development (i.e. the package the tox.ini files "belongs" to) to be skipped from a constraints perspective, as I don't think there is a single case where enforcing this constraints on the package under test would be useful/desired behavior. This would likely involve some preprocessing of the constraints file prior to installation.

I would also like to be able to specify constraints files (zero or more) without (a) having to override install_command (which is apparently deprecated), (b) providing them in deps (which only constraints packages installed via deps), or (c) setting the PIP_CONSTRAINT env var as suggest in that discussion, since that is not visible in the logs and won't work if the project itself is included in the constraints file.

I imagine both would be necessary, since the current options all result in the constraints file getting passed straight through to pip, preventing tox from pre-processing the file.

Alternative Solutions

I have tried pushing this from a pip perspective in pypa/pip#11723, but that feature isn't going anywhere, is likely too broad (at least for my problem), and would need to be utilised by tox in any case.

Maintaining a separate constraints file for each package that we wish to develop on would be costly and confusing. There are likely over 100 projects under the OpenStack umbrella.

Pre-processing constraints files via another tool also does not scale and would result in large-scale duplication of the same snippets across all OpenStack projects.

Additional context

Finding a solution is important for the long-term health of many OpenStack projects, so as always I am happy to work on this once we've an idea of how we should approach this nailed down.