-
-
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] Put both sdist and bdist package data configuration in setup.cfg #2790
Comments
The behavior is heavily dependent on the behavior from distutils, which is currently in the process of being adopted by Setuptools. This request is maybe something we can consider once the two implementations have merged. In the meantime, you may want to consider using |
Hi @mcarans, considering the latest developments and bug fixes in setuptools, this experiment shows that Therefore currently it is possible to control everything from Does this solution works for you? |
@abravalheri I have to admit that having examined what is included in my wheel, I found that the files I had listed in MANIFEST.in aren't there after all even though I have I've realised though that my problem is more fundamental: I am not sure what should be included in the sdist vs what should be included in a wheel and don't know what gets included in each by default. Having searched the web for clear answers, I have not found anything and tried posting a question on StackOverflow, but it was closed as "opinion-based". I have now posted it as a discussion in this repo: #3051 I can then set up my project accordingly and test that |
Hi @mcarans, I had a look in your project, tried to build it locally and it seems that both I noticed that you have in your recursive-include src *.txt
recursive-include src *.yml So I did:
and I noticed that all the files that are supposed to be in the wheel, are indeed in the wheel. Please note that By default the folders I will try to share my opinion with you about the files in the discussion 😄 |
@abravalheri That is extremely helpful. The missing piece of knowledge you've filled for me here is that things outside the package directory (in my case I will now test |
Yeah, Think about the following:
Moreover, let's say another package has a Those are just some reasons why I don't recommend relying on files outside the package directory. |
This information is supposed to be available in https://setuptools.pypa.io/en/latest/userguide/datafiles.html. Please feel free to submit any improvement suggestions to the docs that you think would make them easier to understand 😄 |
Ok, will do The issue is then that to have an sdist containing the recommended files like tests etc. requires having a MANIFEST.in (unless using setuptools_scm). It would be great if there were a flag in setup.cfg to say include all in sdist (as setuptools_scm does) and/or a way to specify everything in MANIFEST.in in setup.cfg. Given what you've said should be included in an sdist and what setuptools_scm does, I'd say the flag could be enough. (Meanwhile, I do plan to migrate to setuptools_scm) (Also I guess one day everything in setup.cfg could be in pyproject.toml simplifying things still further, but that's a separate issue.) EDIT: I've just tested and it appears to me that by default the sdist does contain everything. I did not have to specify in |
@mcarans, just to make sure I would recommend you doing a |
Please note that I was describing my personal approach (and I also recommended using Regarding your new proposal: it is not trivial to implement a "include all" flag. There are lot of things happening in the developer's machine that create transient files. That is why git needs What would be the main value added to the developers if this feature is implemented? Please consider that:
PS: There is a nice article about this topic. |
@abravalheri Thanks for your helpful reply. I was caught out by failing to manually clean before building (not for the first time :-( ), something I hope will be resolved soon by the tools doing the cleaning (although it seems there is debate about whether it is pypa build, wheel or setuptools that should do the cleaning: pypa/build#206 pypa/wheel#147 (comment)) Having tested again and cleaned, I can confirm that I see the issue with working out what should be included by an include all flag that I had suggested. Scratch that idea, but I think that it would be nice to be able to specify what's in MANIFEST.in in setup.cfg somehow, although I understand that it might not provide the granularity that the syntax of MANIFEST.in provides. I could imagine just specifying paths to folders (like docs and tests) and/or files (like pyproject.toml and LICENSE), given that However, I do intend to use setuptools_scm. |
What's the problem this feature will solve?
What data files will end up in sdist or bdist is a little confusing as it is not configured in one place. This stackoverflow answer summarises:
"Basically it goes like this:
MANIFEST.in adds files to sdist (source distribution).
include_package_data adds these same files to bdist (built distribution), i.e. it extends the effect of MANIFEST.in to bdist.
exclude_package_data prevents files in sdist to be added to bdist, i.e. it filters the effect of include_package_data.
package_data adds files to bdist, i.e. it adds build artifacts (typically the products of custom build steps) to your bdist and has of course no effect on sdist."
Describe the solution you'd like
My suggestion is to remove the need for MANIFEST.in by putting the configuration into setup.cfg. Maybe it could go under a new key under [options.package_data] or maybe it would be good to move towards something new like have [build_distribution] and [source_distribution] sections to make it clearer what is going where.
Just throwing out some ideas, but the main aim is to put all configuration in setup.cfg and make it obvious what ends up in the source distribution and what in the build one.
Alternative Solutions
No response
Additional context
No response
Code of Conduct
The text was updated successfully, but these errors were encountered: