-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
remove the setup reader #9099
remove the setup reader #9099
Conversation
1d06c17
to
e461383
Compare
While I agree with the sentiment and intent of this change, I'm not yet convinced yanking it outright is the best option. I'm not decided however. The rationale for my thinking is that the mere fact these issues show up is an indication that dropping the feature might cause more issues than it solves. I'm wondering if the best way forward is to swap the order of the 517 build and setup reader with a deprecation warning. Then drop in a later release. |
so as far as I can see, once you've committed to trying the pep517 build there is never any point in doing anything else after that |
Could we remove only |
Not only the setup.py reader but also the code around checking whether all the available information is present is buggy. (Some things are initialized to empty lists and some to None, it's all kinds of confused about which of these things means what). I prefer to rip off the bandage. If there is still useful code there - well it still is in version control so you can copy it easily enough. Likewise if we think that reading IMO getting to a cleaner sheet here is actually likely to be helpful in restoring #7670 to health. |
98f3a41
to
2088155
Compare
noting that this makes the test scripts (therefore also pipelines) quite a bit slower: in combination with #9103 the effect is that the scripts are pretty much always doing pep517 metadata extraction for source packages in fixtures. if that motivates someone to figure out how to make the pep517 metadata extraction faster, that could turn out to be a win... alternatively most of the slowdown can be mitigated by reinstating the generated metadata files removed in #9103 ( |
For posterity. Here are the list of test cases that call This should also provide insights into what fixture is being used, in some of these test cases (the ones that do not test Poetry's setup file handling), we could simply swap out the package fixture we use as well. But in the long run, making the metadata extraction more efficient is the way to go.
|
2088155
to
594e716
Compare
594e716
to
f22ddbd
Compare
f22ddbd
to
8ac045b
Compare
8ac045b
to
0ca6271
Compare
The isolated builds are improved further in #9168. We should eventually also deal with some level of caching for build environments. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In general, I agree with the change. Couple of questions regarding the removed tests. Otherwise, lgtm.
Will need another reviewer from @python-poetry/core to also approve as this is a major change in established process for extracting package metadata.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approving form my side.
Will need an additional reviewer from @python-poetry/core to also approve as this is a major change in established process for extracting package metadata.
#9168 (comment) - something from that pull request does not fit well with this one |
776ff27
to
9ac6e48
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approving again.
Merge pending on secondary approval from @python-poetry/core.
9ac6e48
to
ca728ff
Compare
ca728ff
to
df64b78
Compare
This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
fixes #9066, probably others
the more I think about it the more I reckon that the setup reader and mechanics around it are buggy beyond repair.
eg I realised today that even though the setup reader might correctly identify that some piece of metadata is not set in either
setup.py
orsetup.cfg
- it might still be completely wrong to declare that the value is missing, because this code knows nothing about PEP621-stylepyproject.toml
.indeed, an approximately empty
setup.py
is recommended by the "how to modernize" guide as "perfectly fine".as discussed in #9066, the python ecosystem is in a different place than it was when this was written: pretty much all of the popular packages are providing wheels these days and so the value in trying so hard to avoid building from source is much reduced.
(It might be worth someone making something along the lines of #7670 work at some point. That tries to read metadata from a PEP-621
pyproject.toml
without performing a build. In the current ecosystem, if you can get all that you need that way then you likely should.)meanwhile let's rip out the code that gives wrong answers, and just take the performance hit.