Inconsistent default behavior of `include`
envgap__python-poetry__poetry-9691
01 / FAILURE SIGNATURE
As reported upstream
No identifying execution failure has been captured.
Not a benchmark task.
- The project already builds and runs before the fix, so there is nothing to repair.
02 / ENVIRONMENT RECIPE
- Base commit
ab0880c2beb07c34427f3ae927af24fc675bbd97- Manifest
pyproject.toml- Reproduce
Awaiting issue-specific recipe- Run under trace
Awaiting a meaningful runtime command
03 / ORIGINAL ISSUE TEXT
python-poetry/poetry #9691 · read the original issue
Before diving into the issue, a short clarification: 1. There are [packages includes](https://python-poetry.org/docs/pyproject/#packages), which default to sdist **and** wheel. 2. There are [includes](https://python-poetry.org/docs/pyproject/#include-and-exclude), which (according to the docs) default to **only** sdist. These different defaults can be confusing, but might make sense because you normally want to include packages in sdists and wheels but additional data like tests and a changelog only in the sdist. # Issue The behavior for [includes](https://python-poetry.org/docs/pyproject/#include-and-exclude) (the second one) is different for files and directories: - files are included in both sdist and wheel - directories are only included in sdists Considering that the docs were "fixed" recently in #8852 to describe the behavior for directories - previously, it described the behavior for files - I wondered which behavior is correct and which is the bug? Events of confusion in chronologically order: - python-poetry/poetry-core#6 added support for includes and describes that they should be only sdist per default. This PR has already contained the bug. - python-poetry/poetry-core#114 changed the default behavior for packages includes (first one), but confusingly added a test for includes (second one) - actually testing the bug instead of the change. Thus, we cannot trust the test. - #2268 added docs that it defaults to sdist and wheel. - #8852 changed the docs that it defaults to only sdist. We can be sure that the initial intention was to default to "only sdist". However, I am not sure if the behavior should be changed to "sdist and wheel" later or if it was just a confusion between the two types of includes. Thus, the big question: **What should the default be?** - sdist and wheel for package includes (first type) and sdist only for includes (second type) - pro: You normally want to include packages in sdists and wheels but additional data like tests and a changelog only in the sdist - contra: different defaults - sdist and wheel for both types of includes - pro: same defaults - contra: maybe improper default for one type
04 / LABELS
Labels from the report text only; not yet run
No supported category has been assigned.
Label rules and the text that matched
[]