-
-
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
[FR] Automatically include files mentioned in pyproject.toml
(e.g. license = { file = ...}
) into the sdist
#3570
Comments
Hi @abitrolly, thank you very much for reporting this issue. Quick question before investigating this issue deeper: have you tried to add the By default The Footnotes
|
@abravalheri I expected the file to be included automatically, because it is referenced. If it needed to included explicitly, how can I do this from |
This sounds like a reasonable expectation. If I understood correctly, this issue would be better classified as a feature request. Currently setuptools does not offer this capability1. (I might have seen some similar discussion but in the context of
This specific functionality is only offered via [build-system]
requires = ["setuptools", "setuptools-scm"]
build-backend = "setuptools.build_meta" Footnotes
|
Fell free to reclassify it. Is there anything that is needed from my side? |
pyproject.toml
(e.g. license = { file = ...}
) into the sdist
This feature request is closely related to #2821.
Please feel free to submit a PR :) |
@abravalheri I am not even sure where to start with. |
We are probably in the same boat :P The biggest challenge here is that the configuration is solved before hand, so all the parameters are expanded. By the time the |
If the license field is already expanded to include the file as text, then why it complains about it missing?
|
Because the It is a 2 stage process:
|
The same would be very useful for dynamic metadata too (e.g. |
@abravalheri if |
@abitrolly, there are a lot of things going on here. For example, I don't believe the packaging specs (at least the version that setuptools uses) prevents the backend to re-evaluate the configuration files (of course I might be wrong). If setuptools decides to re-evaluate the configuration files, than we can see that a file is missing in the source distribution (which ideally contain all the files necessary to build the package from scratch). So far this is the information in the setuptools documentation about how to control the files in the
This hopefully conveys the idea that if a use case deviates a bit from what setuptools adds to the I think we all agree that what you ask is a nice enhancement. That is why I invite anyone in the community that would like to work in this feature to send us a PR. |
@abravalheri why isn't possible for I am curious if there is a conversion graph that shows what field should be converted to what, and what role |
I have to disagree with this point because it directly contradicts the previous paragraph that you quoted: "For the most common use cases, setuptools will automatically find out which files are necessary for distributing the package". Arguably, the |
Hi @abitrolly, you can try to skip the sdist step by running
I am not sure if I understand the question, but the field conversion is described in PEP 621. Unfortunately there is no graphical representation available in the community yet. |
Hi @GergelyKalmar, we can debate about a lot of aspects here... I think that everyone here aggress that it what has been proposed is a nice enhancement to setuptools. So the approach of marking this ticket as a feature request and adding the
If I am not wrong, PEP 621 does not dictate that files mentioned in |
This also effects dynamic dependencies with |
For completeness: I just tested, and apparently |
I don't like the complexity of layering wheel building logic on top of legacy sdist logic, but I am glad that the problem is fixed. |
I don't think But I am afraid this decision has a higher scope than setuptools (as it's been debated in PEP's). Please feel free to open a new thread in the Python Discourse. |
@abravalheri logic != format. |
Can you stop speaking in riddles - what logic is it you are referring to? |
@layday the logic.
Instead of that, the logic goes through sdist and eggs, which is turn touches HTH. |
@abitrolly
The I believe that in the long run, we would like to replace the |
@abravalheri see, instead of discussing technical details of converting This is the legacy for me. I am not interested in that stuff anymore, and I don't have time to understand |
I'm not sure I see any issues anymore, with this fix you can now use a I agree that scattering the project directory with "random" folders like |
|
@abitrolly I think I understood now what you mean. And it is a perfect valid opinion. Thank you very much for the issue report. I hope the problems were fixed now. To anyone in the community (not only you 😁): If there is anything that you belive can be improved in Setuptools is a community project and love contributors! The maintainers will try to help as much as we can. |
setuptools version
65.3.0
Python version
3.10
OS
Fedora 36
Additional environment information
No response
Description
Specifying license information as
license = {file = "UNLICENSE"}
gives warningwarnings.warn(f"File {path!r} cannot be found")
when building package.Expected behavior
No warning.
How to Reproduce
UNLICENSE
pyproject.toml
refer to it aslicense = {file = "UNLICENSE"}
python -m build
or
Output
The text was updated successfully, but these errors were encountered: