Support --use-pep517 and --no-use-pep517 inside requirements files.

[foundry-markf]

This is another attempt to address #6438 after I saw #6447 had not been finished off.

The reasoning behind putting some effort into this is multi-fold:

• we have PyPi dependencies that we cannot update currently (since it involves a lot of work due to breaking changes), and the upstream developers are no longer maintaining, and does not contain a pyproject.toml, and we don't have capacity to address upgrades before pip 25.3 appears
• I'd prefer to address CI and local development in the same way; although we can fall back on PIP_USE_PEP517 or a pip.conf this is not shared between workflows and will result in upset. If I can fix it by adding an option to a requirements file, this is used by all modes of operation
• I did not dig deeper to add this as a per-dependency option; I don't need that level of control, and at some point in the future, I expect not to need it at all (re first point, when we do the legwork to upgrade dependencies).

I left --no-use-pep517 in from the original PR/issue, not that I need it, but simply for agreeable symmetry

I realise pip 25.3 is on the horizon, so this is very late coming, but appreciate anyone looking over it. Thanks.

[notatallshaw]

Hi @foundry-markf thanks for opening a PR to pip, please be aware that all all pip maintainers are currently volunteers and it may take awhile for someone to review.

That said, let me know if you need any help fixing pre-commit failure, you can run locally following the linting step in the dev guide: https://pip.pypa.io/en/stable/development/getting-started/#running-linters

[notatallshaw]

I'm thinking that --use-pep517 will soon be irrelevant as it will be defaulted for all packages so it would only make sense to add --no-use-pep517? Or am I missing something about this?

As for adding what options are allowed in the requirement file, I definitely would want to some other maintainers to weigh in, I am going to be uncomfortable approving that. If approved we should also give a heads up to uv, which will not be able to support this feature (they are PEP 517 only).

[pfmoore]

I agree, I'm uncomfortable with adding this to the requirements file. While the file format is technically owned by pip, it's used widely enough that we need to be careful about disrupting other users. Also, given how far we now are along the process of removing non-PEP 517 workflows, I don't think this is a particularly worthwhile feature to add (we'd either be ripping it out again in a few releases, or it would be left as a confusing legacy option that did nothing).

Furthermore, there's no real evidence that this feature is needed except possibly by a very small minority of users. The original issue was raised in 2019, over 6 years ago, and there was very little support for it beyond a general sense that it would probably be useful for consistency with other command line options. And any consistency argument looks extremely weak now, when the whole idea of non-PEP 517 workflows is nearly dead.

So I'm -1 on this. I think we'd be better simply closing #6438 as "won't fix" at this point.

Sorry @foundry-markf - I realise you have a need for this in your specific environment, but honestly, you can globally configure pip to use PEP 517 via a config file or environment variable. That may be more awkward for you, but we have to balance (extremely!) limited maintainer resource against benefits here, and I don't think this meets those criteria.

[foundry-markf]

Thank you for the feedback @pfmoore and @notatallshaw . I appreciate that you took the time to look into it, and that you gave reasoning for a downvote.

This at least gives me direction in my org on what to do.

I note that the main branch still reports the deprecation warning for non-compliant packages, rather than a hard failure, e.g.

DEPRECATION: Building 'pluginbase' using the legacy setup.py bdist_wheel mechanism, which will be removed in a future version. pip 25.3 will enforce this behaviour change. A possible replacement is to use the standardized build interface by setting the --use-pep517 option, (possibly combined with --no-build-isolation), or adding a pyproject.toml file to the source tree of 'pluginbase'. Discussion can be found at #6334

I'm expecting a hard failure when 25.3 is release. Is that still the case?

If it is, will there be a pre-release of 25.3 that can be tested ahead of time, so there isn't a surprise when 25.3 lands?

Thanks!

[notatallshaw]

I'm expecting a hard failure when 25.3 is release. Is that still the case?

It depends whether the project builds with --use-pep517 or not. PEP 517 doesn't hard fail without a pyproject.toml, as per the spec:

If the pyproject.toml file is absent, or the build-backend key is missing, the source tree is not using this specification, and tools should revert to the legacy behaviour of running setup.py (either directly, or by implicitly invoking the setuptools.build_meta:legacy backend).

In this case pip will call the backend setuptools.build_meta:__legacy__, this is very similar to calling setup.py bdist_wheel, except by default PEP 517 is running in an isolated environment. Most projects that get this deprecation warning will not fail to build, as evidenced by the fact that uv has grown quite popular and they have only ever supported the PEP 517 behavior.

If it is, will there be a pre-release of 25.3 that can be tested ahead of time, so there isn't a surprise when 25.3 lands?

As the deprecation warning states, you can opt into this behavior with --use-pep517 (or set the env var PIP_USE_PEP517=1 or set your user config pip config set global.use-pep517 true) and see if there are any unexpected build failures.

[foundry-markf]

@notatallshaw Ah, I think I had misunderstood what happens after the deprecation.

I have tested the set of packages we pull with PIP_USE_PEP517 and --use-pep517 and it's successful.

I had interpreted the

using the legacy setup.py bdist_wheel mechanism, which will be removed in a future version. pip 25.3 will enforce this behaviour change

that I had to do something to our pip install invocations when 25.3 is released to keep the legacy packages building.

But I just had a re-read of comments above, in particular,

I'm thinking that --use-pep517 will soon be irrelevant as it will be defaulted for all packages

so as our installed packages work with --use-pep517, I actually don't need to do anything upon the 25.3 release, because that's the default.