Remove --global-option and --build-option flags

[sbidoul]

The removal of these options was scheduled for 23.3.

closes #11859

[sbidoul]

Perhaps we should postpone this, since setuptools does not seem to accept --build-option via config settings. pypa/setuptools#2491 (comment)

[pfmoore]

I'm inclined to say that at some point, we need to bite the bullet and be explicit that this is a setuptools issue, not a pip one, and we won't maintain the legacy options indefinitely. But having said that, there's no particular reason we have to remove these now, so leaving them for a while longer is reasonable.

The docs already note that the options only apply to the legacy setup.py path, so maybe at this point we just need to switch the dependency around, and assume we're OK to start removing the setup.py path now, with these options simply becoming useless once that happens, and we remove them as part of that work?

[pradyunsg]

Let's defer this for now -- I do agree that the reason for that is a setuptools issue and not a pip one, but I don't like the idea of leaving out users in a state where there isn't a way to achieve parity with an earlier release of pip due to us removing an option that serves a reasonable user-need but it's not served due to setuptools not being ready for it.

I also don't like the idea of having folks point pitchforks at pip/setuptools maintainers for this, given that this doesn't really feel all that urgent and it's going to cause user churn when this gets removed anyway. Being able to say "here's what you need to change to" is definitely more palatable than "there is no equivalent to that thing". 😅

maybe at this point we just need to switch the dependency around, and assume we're OK to start removing the setup.py path now, with these options simply becoming useless once that happens, and we remove them as part of that work?

Maybe?

It'd add friction to that removal though, and I think making this removal a slow burn vs a hard break is the choice we'd have to make here. My guess is that a slow burn around this (i.e. not coupling the two removals) would be a smoother rollout, but I'm also not (yet?) in possesion of a crystal ball that'd tell me the future.

[pfmoore]

I think that the critical point here is what's being blocked on this. Removing the legacy setup.py code path has been an ongoing effort for some time now, and I'd like to see it resolved. But in all honesty, there's very little depending on it - pip's feature development (and for that matter, new packaging features and standards in general) has slowed down at the moment, so this isn't actually the blocker that it might be if things were moving more rapidly.

So I'm fine with deferring, but if anyone feels that progress on something else is being delayed by leaving this (and the setup.py code path) around for a while longer, please speak up!

[sbidoul]

I think at this stage it only causes a slowly growing maintenance burden, but does not block pip evolution. So no urgency indeed. I postponed to 24.0 and we'll reevaluate then.

[ichard26]

Bump. This is currently scheduled for 24.2 which is due in ~a month. I'm not familiar with this functionality of pip so I don't have much to say other than we need to reevaluate whether we should remove these flags in 24.2 or continue to defer the removal (until setuptools can figure out a replacement for these flags?).

/cc @sbidoul

[sbidoul]

We can continue postponing.

At some point we do want to remove setuptools special cases from pip, though, but there is no particular urgency for these options, knowing that we need to deprecate our uses of setup.py develop first (#11457).

[ichard26]

Coolio, I've deferred this to pip 25.0 (wait, it's going to be 2025 already 👀) .

[sbidoul]

@ichard26 we'll need to replace gone_in="24.2", otherwise it will enact the deprecation :)

[ichard26]

Ah yes, of course. Thank you for reminding me of that :)

Please see #12837.