-
-
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
Setuptools does not pass config_settings through backend #2491
Comments
@di why not put this into PR? |
@abitrolly Because I'm not sure it's right. The means by which a frontend passes these arguments to the backend is not well defined. |
@di what is missing here https://www.python.org/dev/peps/pep-0517/#config-settings ? |
Because it is hard to implement in current form pypa/setuptools#2491 (comment)
@abitrolly All these phrases from that section indicate that this is not well defined:
|
@di I proposed some clarifications in python/peps#1766 Not sure where it should go from there. Normalizing parameters to be passed as |
FYI I am also in favor of removing the dashes, I don't think they are needed in PEP 517. |
Incidentally, global options in setuptools seem to mean something different than they do in pip where they are placed in front of the setuptools command. Here, they are appended to the command. pip users might find the discrepancy surprising. I'm not sure why arguments to |
I'm sure the reason why the PEP is non-specific about the format is because it would be difficult for a protocol like that to be specific without being over-constrained for a particular use-case.
I imagine that the Regardless, what I'd like to see happen is for someone to examine the code and determine all the command-line parameters setuptools currently solicits that would be relevant to a build backend... and determine at what scopes those settings are relevant (globally, per command, other?). From there, we can create a scheme, something simple, maybe namespaced, to accept those parameters through config_settings. |
@layday if you want to push this further, I guess the right way it to do what @brettcannon said in python/peps#1766 (comment)
|
I don't know how changing lists to comma-separated value strings in the PEP is going to help here. |
@layday because PEP doesn't specify how to pass lists, nobody wants to write this. |
Hi @abitrolly so just to clarify for myself and possibly for others following this issue, is the next step here to discuss potential changes in https://discuss.python.org/c/packaging/14 so that the PEP is updated with well defined statements? |
@dixonwhitmire yes, that's correct. |
Just encountered this. First there is an issue with build itself: passing def _fix_config(self, config_settings):
config_settings = config_settings or {}
config_settings.setdefault('--global-option', [])
if not isinstance(config_settings['--global-option'], list):
config_settings['--global-option'] = [config_settings['--global-option']]
return config_settings Second issue is that setuptools does NOT conform to https://www.python.org/dev/peps/pep-0517/#config-settings. Although, even better would be to adjust |
Hi @PolyacovYury , I think the first part of the problem you described was solved in Regarding the second part:
It is not immediately clear to me that the spec mandates that |
I commented on this upthread:
This is all setuptools-specific stuff, the spec has no notion of global options nor does it expect that options will be passed to a CLI. |
Hi @sbidoul, yes there is still the challenge of what to do with @sbidoul, @layday, @henryiii do you believe that the best we can do right now is to only pass I don't have experience with these extra parameters, but if you think that this is the best way forward we can craft a PR that does that... (I am considering that |
This implements a custom build backend, inspired by the [solution used by Pillow.](python-pillow/Pillow#7171) install-option is deprecated and was removed with pip 23.1. The comonly accepted solution seems to be to define a custom build backend for now pypa/setuptools#2491 (comment) This commit changes the usage from `--install-option` to `--config-settings`.
I don't have experience with these parameters either, but what I can tell is that |
pip passes its config settings to all commands as far as I remember, meaning that the build option is passed to every build hook when specified this way. This is also the behaviour of build as of v1.
Restricting passing config settings to build_wheel is not a good solution. There is demand to pass config settings to all of these commands which is evidenced on the build tracker.
The easiest thing for setuptools to do in my mind is to introduce a set of “legacy” namespaced build options, one each for egg_info, sdist and wheel. Paper over the cracks while we hash out what is to become of setuptools’ config settings.
Sent with [Proton Mail](https://proton.me/) secure email.
…------- Original Message -------
On Monday, October 2nd, 2023 at 16:14, Stéphane Bidoul ***@***.***> wrote:
> ***@***.***(https://github.com/sbidoul), ***@***.***(https://github.com/layday), ***@***.***(https://github.com/henryiii) do you believe that the best we can do right now is to only pass --build-option to bdist_wheel and ignoring it in any other command?
I don't have experience with these parameters either, but what I can tell is that pip only passes it's --build-option to the bdist_wheel command. So yes, I think what you propose is a good stop gap until a broader solution is designed.
—
Reply to this email directly, [view it on GitHub](#2491 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AHNRFWCLJEBGFPYMUDIPUVDX5K43ZAVCNFSM4U66OTDKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCNZUGI4TSNJYGE3A).
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
This implements a custom build backend, inspired by the [solution used by Pillow.](python-pillow/Pillow#7171) install-option is deprecated and was removed with pip 23.1. The comonly accepted solution seems to be to define a custom build backend for now pypa/setuptools#2491 (comment) This commit changes the usage from `--install-option` to `--config-settings`.
In my understanding the When pip invokes So from that point of view it makes sense for the setuptools backend to only pass the With that little change we'd have simple and clear transition path for users when pip drops the legacy |
I don't know why the PEP 517 options in setuptools were modeled on pip, but the main audience here isn't people transitioning from legacy pip installs to isolated pip installs - it's people transitioning from invoking setup.py directly, to build. A |
I don't disagree a better mechanism for setuptools config settings is needed (and I personally have no idea what it should be - I'll leave that to setuptools experts), but that should not prevent a short term fix for the |
This implements a custom build backend, inspired by the [solution used by Pillow.](python-pillow/Pillow#7171) install-option is deprecated and was removed with pip 23.1. The comonly accepted solution seems to be to define a custom build backend for now pypa/setuptools#2491 (comment) This commit changes the usage from `--install-option` to `--config-settings`.
Right now, I don't think we are in a good position even to "paper over the cracks". The situation with Solving this and related problems is one of the major steps in creating a more definitive solution1. So if the most immediate concern is to offer a solution for people migrating from direct running On the other hand, if the most immediate concern is to offer a solution for compatibility with Footnotes
|
This may unlock a workaround to #3237. Edit: hm, or not, due to the .egg-info directory. |
I was trying to see if we have further agreement on this, but I guess I can prepare a PR for that ... (update: #4079)
That is the thing... Also some packages will simply not work if |
In pypa#2491 (comment) the discussion seems to lead to the idea that it is better for now to avoid passing any `--build-option` for commands that are not `bdist_wheel` in `setuptools.build_meta`.
I opened a discussion in #4083 for a more long-term approach. |
In pypa#2491 (comment) the discussion seems to lead to the idea that it is better for now to avoid passing any `--build-option` for commands that are not `bdist_wheel` in `setuptools.build_meta`.
In pypa#2491 (comment) the discussion seems to lead to the idea that it is better for now to avoid passing any `--build-option` for commands that are not `bdist_wheel` in `setuptools.build_meta`.
It seems that #4079 made
This is exactly our use case which was completely broken by #4079, I've opened a PR reverting it in #4218 as #4079 seems to clearly be a regression. |
Hi @jameshilliard, I just pushed the bugfix you provided in /fyi @sbidoul, the change in #4217 should not introduce problems for |
… OV wheel (#27190) ### Details: - Direct `setup.py` calls are deprecated and using `build` package instead is recommended ([source](https://packaging.python.org/en/latest/discussions/setup-py-deprecated/)) - PR simplifies wheel building by using `python -m build` for all pip versions - A new build dependency has been added since `build` is not supplied with Python - `setuptools` (our current build backend) is not integrated well with `config_settings`, which leads to an unfriendly looking workaround for passing build settings (more details in pypa/setuptools#2491) - Migrations for other wheels will be delivered in separate PRs as they have a different scope (for example `openvino_dev` also requires migration from using `pkg_resources` package) ### Tickets: - CVS-155190
… OV wheel (openvinotoolkit#27190) ### Details: - Direct `setup.py` calls are deprecated and using `build` package instead is recommended ([source](https://packaging.python.org/en/latest/discussions/setup-py-deprecated/)) - PR simplifies wheel building by using `python -m build` for all pip versions - A new build dependency has been added since `build` is not supplied with Python - `setuptools` (our current build backend) is not integrated well with `config_settings`, which leads to an unfriendly looking workaround for passing build settings (more details in pypa/setuptools#2491) - Migrations for other wheels will be delivered in separate PRs as they have a different scope (for example `openvino_dev` also requires migration from using `pkg_resources` package) ### Tickets: - CVS-155190
The
build
project now has a--config-setting
flag to pass options to the backend:I wanted to use this to set
wheel
's--plat-name
argument like so:I found that this worked as expected until the settings got to setuptool's
_build_with_temp_dir
function:setuptools/setuptools/build_meta.py
Lines 190 to 200 in d368be2
In this example,
_build_with_temp_dir
gets called withconfig_settings={'plat-name': 'foo'}
, which then gets 'fixed' intoconfig_settings={'plat-name': 'foo', '--global-option': []}
, and then setuptools ignores everything inconfig_settings
and only considers--global-option
.It almost seems like
--global-option
itself could be used for this, but unfortunately it doesn't work as it's value is passed to lots of things that don't accept the arguments I'm hoping to pass:I created a commit that "fixes" this for me as a proof of concept: fc95b3b
Possibly related issues:
The text was updated successfully, but these errors were encountered: