-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
build_meta:__legacy__ config_settings not compatible with pip options #1928
Comments
As mentioned in pypa/pip#4383, we likely can't have a clean mapping from pip's Maybe we could expose config settings for pre- and post-command args for each of |
@pypa/setuptools-developers A gentle ping! We'd like to move forward on the pip-side of things, w.r.t. config_settings and addressing this difference between how pip vs setuptools.build_meta handle these options would be great! |
I'll be honest; I'm struggling with this one a bit. I really don't like the idea of proliferating pre- and post-command args that make reference to specific distutils commands. On the other hand, it seems like what you may be proposing is that setuptools honor |
…obal-option to define options that apply before the distutils command. Fixes #1928.
Does the commit above achieve what you're after? It doesn't break any tests, so apparently the existing |
I am very uneasy about the whole Maybe this is just a UI question about I guess I can't think of a better "escape hatch" in general, but I think we really need to step up our game with extras, to make it easier to avoid complicated installation options ever being passed to |
I agree enthusiastically with Paul, though to be sure, I've never been affected by the build-time concerns that are driving these custom options. |
@pganssle, @jaraco, this happens true if If all the packages you are installing are available as wheels, If you using I think the best thing we can do now is to go with @jaraco's proposal in b519c18, for 2 reasons:
|
@chrahunt, for the time being I just aligned In the future we probably want to have a proper definition of Please let me know if v64 addresses the original concernl |
Summary
Running
pip wheel --global-option ARG
callssetup.py ARG bdist_wheel
, but runningsetuptools.build_meta.build_wheel(config_settings={"--global-option": ["ARG"]})
callssetup.py bdist_wheel ARG
! Can we make pip and setuptools behave the same?Details
setuptools.build_meta:__legacy__
(I will drop__legacy__
since it is just a wrapper aroundbuild_meta
) supports the--global-option
value inconfig_settings
, but places it at a different location in constructedsetup.py
invocations than pip does. pip supports a--build-option
parameter for post-command args, which matches the currentsetuptools.build_meta
--global-option
behavior.This can be shown with the following script
t.sh
Here is the output of the script on my machine (Ubuntu 18.04, Python 3.8.0)
Output
Note that with the pip invocations, the args are:
whereas invoking
setuptools.build_meta
results inThe differences:
--global-option
s tosetup.py egg_info
setuptools.build_meta
passes them afteregg_info
--global-option
s tosetup.py bdist_wheel
bdist_wheel
setuptools.build_meta
places them afterbdist_wheel
--build-option
s tosetup.py bdist_wheel
bdist_wheel
setuptools.build_meta
does not use this valueFor where in code this is happening, see:
setuptools.build_meta
here, whereconfig_settings["--global-option"]
comes after the command namebuild_options
We would like to eventually transition away from having setuptools-specific code in pip by e.g. delegating to the legacy backend (pypa/pip#5204). In that context, can we discuss how to resolve these differences and pass the arguments to the backend appropriately?
The text was updated successfully, but these errors were encountered: