Deprecate `--global-option` and `--build-option`

[sbidoul]

The use of --global-option and --build-option currently trigger a warning, recommending --config-settings.

I propose to deprecate them with a 6 month notice and remove them in 23.3.

After that, we can consider dropping the legacy setup.py egg_info + setup.py bdist_wheel code paths and switch to using the default build backend without build isolation for projects without pyproject.toml.

[pradyunsg]

Alternatively, we could forward those options to backends on a pyproject.toml based build, via config settings?

[uranusjr]

Realistically the option translation is only useful for projects using setuptools, so we should first ask whether setuptools devs are interested in establishing such translation.

[sbidoul]

Alternatively, we could forward those options to backends on a pyproject.toml based build, via config settings?

I guess it's possible in principle, although I can imagine some difficulties (e.g. does setuptools distinguish global and build options in config settings?).

This would also likely trigger requests for adding --build-option to pip install, since it's currently in pip wheel only.

So, all in all, I think it would be quite a bit of fuss for little benefits. Especially since we'll likely want to drop these setuptools specific options at some point in any case.

[pradyunsg]

These are both referenced in the setuptools implementation today: https://github.com/pypa/setuptools/blob/be6c0218bcba78dbd4ea0b5a8bb9acd5d5306240/setuptools/build_meta.py#L158

As far as I can remember, these have been implemented from fairly early on in the build-backend provided by setuptools.

does setuptools distinguish global and build options in config settings?

Yes.

This would also likely trigger requests for adding --build-option to pip install, since it's currently in pip wheel only.

Sure, and that's a valid request, no? It pushes for consistency, and I'm ~sure that we can leverage that consistency to make the codebase clearer around this aspect as well.

So, all in all, I think it would be quite a bit of fuss for little benefits.

I don't think so. Something that we spent a lot of energy toward ensuring was that we're able to transition users toward the newer build mechanism without being too disruptive to their workflow, outside of certain bits of functionality that don't have equivalents that are being removed (and that goal hitting Hyrum's law).

However, this is functionality that we can implement in a manner that avoids disruption. The PEP even has an example of the behaviour I'm proposing in the config settings section (https://peps.python.org/pep-0517/#config-settings).

[pfmoore]

I can see the point of translating these options to config settings. But I think we should consider the larger question, do we want to retain these options forever, or not? There are arguments both ways:

1. (Keep) People are (presumably) using these right now, so we'd break workflows by removing them.
2. (Remove) There's a standards-based replacement which is already supported, so migration is straightforward.
3. (?) The existing implementation is incomplete (--build-option on install). We can, of course, complete it.
4. (Remove) The flags add a fair amount of complexity (command line options, requirements file support, threading the flags through the various call chains, etc.)
5. (Remove) The flags are completely setuptools-specific, and we have a stated goal of removing all special consideration of setuptools.
6. (Keep) The PEP calls this example out explicitly (although that section is only an example).

Personally, I find the arguments for removal compelling, but not urgent. The 6-month deprecation seems like a reasonable compromise, but I'd be fine with extending it further. I'm not convinced there's a case for retaining the options forever (and by implication, I'm against "fixing" the problem of install not having a --build-option flag).

For me, the main point is that this is another "remove special-casing of setuptools" change, and doing it in parallel with the removal of the setup.py call logic makes sense, both from an internal POV, and in terms of user disruption (having a single period of "removing setuptools-specific features" disruption for users, is arguably better than having a series of separate disruptions).

[sbidoul]

For me, the main point is that this is another "remove special-casing of setuptools" change, and doing it in parallel with the removal of the setup.py call logic makes sense, both from an internal POV, and in terms of user disruption (having a single period of "removing setuptools-specific features" disruption for users, is arguably better than having a series of separate disruptions).

This is also my point of view. In particular, since users still relying on --install-option must switch to something else with 23.1 it is better to state clearly right now that --global-option is not going to be around forever so they don't settle on that to discover in one year that we want to remove them too.

[pradyunsg]

Fair enough! Color me convinced that we should deprecate + remove these. :)

[sbidoul]

Merged in 23.1. Moving this issue to 23.3 for removal.