1.0.3: tests/ directory missing in idst pypy tar ball

[kloczek]

Looks like something is wrong with https://pypi.io/packages/source/p/poetry-core/poetry-core-1.0.3.tar.gz because in that archive is not included tests/ directory.

[finswimmer]

Why it should?

[kloczek]

Obvioely to have test suite included in dist tar ball which wou;d be possible to fire on for example packaging poetry to confirm that some basis functionalieties of the poetry module or some other build env components used by poetry test suite are ok :)

[eli-schwartz]

As implemented in #1133 it is possible for poetry-based projects to specify files which are added to sdist but not wheel. https://python-poetry.org/docs/pyproject/#packages

The intention is for people to be able to include test data and the like inside sdist archives, which is exceedingly useful for third-party ecosystems e.g. running integrated unittests when shipping packages... rather than needing to do painful contortions with the github repo and post processing.

It is wonderful that other projects using poetry can now ship tests in their source code releases. It would be even nicer if the sdist releases for "poetry" and "poetry-core" themselves could make use of this feature!

[kwshi]

More reasons to include tests in the sdist tarball:

• Including tests in package tarballs is common, and arguably standard, practice among Python packages (examples: requests, black, pandas).
• Doing so makes it possible for third-party package repository maintainers (Arch community repos, Void, SUSE) to run tests as part of the package release flow (as @eli-schwartz mentioned above). There is also a related discussion in Include tests is poetry's sdist #1109.

[eli-schwartz]

Please note that the entire rationale for adding a new feature to poetry was, specifically, that it is in fact useful for project developers to utilize the feature. Poetry should be brave enough to dogfood this UX.

The PyPI releases contain both sdist and wheel. The point of a wheel is to be very quick to install prebuilt code that is lean and small to download. The point of an sdist is to be source code. Source code should include everything necessary to build and test the project, because if not, then why on earth would anyone ever use it instead of the wheel???

Why is it so necessary for the process of trying to help more people get a copy of the poetry software, to be pain and suffering? All I want to do is help people get poetry. Part of doing that is to do end to end tests and verify that poetry works in the ISV ecosystem, just like we do for other python projects, and just like we do for software written in C/C++/go/rust and built using cmake or autotools or what have you.

It's really depressing that a minority of python developers think that python is somehow a special case where no one should care if it works and just YOLO distribute untested build artifacts (and maybe have tests that don't even work outside of the developer's private laptop or hey, CI runners using the root account). This attitude doesn't fly in more universally professional software ecosystems. Stop dragging down the reputation of python. Please.

[clintonroy]

It's really depressing that a minority of python developers think that python is somehow a special case where no one should care if it works and just YOLO distribute untested build artifacts (and maybe have tests that don't even work outside of the developer's private laptop or hey, CI runners using the root account). This attitude doesn't fly in more universally professional software ecosystems. Stop dragging down the reputation of python. Please.

Please keep at least a neutral tone when demanding time from volunteers. If you advocate your view in a way that explains the benefits and don't shit on them, maybe, just maybe, you'll catch more flies with honey than vinegar.

[eli-schwartz]

@clintonroy one specific person keeps on pushing back against reasonable requests without understanding the issue -- same with closing #1645 (I mentioned before about test suites only running in docker).

Thanks to @abn both times for helping to solve the ticket.

[abn]

@eli-schwartz just to be clear; I do not endorse the perceived demeanour or tone of your comments earlier in the issue. I feel that the questions asked were reasonable and push back is good to validate the rationale/impact. Sometimes when dealing with a lot of issues, things get closed accidentally or missed. It happens. As a specific example, #1645 was closed because of the comments immediately before the closure.

We do not know what we do not know. Exlaining the rationale behind requests and how it benifits the community will definitely help is prioritise things better. We are, as pointed out above, volunteers trying to keep a useful project moving forward. Please bear with us while we make time to make this happen.

[eli-schwartz]

I feel that the questions asked were reasonable and push back is good to validate the rationale/impact.

We do not know what we do not know. Exlaining the rationale behind requests and how it benifits the community will definitely help is prioritise things better.

OK. So, this ticket was opened 2 weeks ago. Within 2 hours of it being filed, a project member
a) asked why it was needed
b) removed the triage label

Within another 2 hours, the ticket submitter answered why:

to have test suite included in dist tar ball which wou;d be possible to fire on for example packaging poetry to confirm that some basis functionalieties of the poetry module or some other build env components used by poetry test suite are ok

Following this first-4-hours answer, the ticket saw the chirping of crickets for 2 weeks.

Following this wait period, I left a comment pointing out that the poetry specification added a pyproject.toml feature explicitly intended to let poetry.core.masonry.api third-party ecosystem users implement "include tests directory in the sdist PyPI tarball", therefore it clearly is useful and it would be great if poetry itself provided said usefulness. I also indicated my disappointment that this concern is buried and ignored, though perhaps I didn't convey that clearly enough.
(addendum: the feature was added in response to #1109, which asked for poetry to ship tests in the sdist, but which got closed by a stale bot months after the feature was implemented, still without utilizing the feature in poetry itself.)

So, for the record, I'll just make that clear. When I used harsh language to complain about "a minority of python developers think that python is somehow a special case where no one should care if it works and just YOLO distribute untested build artifacts" etc. I was specifically upset that it seemed like the response to this ticket was "your answer is insufficient, I don't see why you need tests for your packaging of poetry, so I'll just un-triage this ticket and forget about it for weeks on end".

So far on issues I as a distro packager am watching/interested in, I'm 3 for 3 with "Sometimes when dealing with a lot of issues, things get closed accidentally or missed. It happens." Two of these "things get missed" were about people trying to reproduce a successful run of the testsuite outside of Github Actions (which poetry development is not apparently affected by), the third was waiting most of a year for poetry to import setuptools instead of distutils when explicitly generating a setuptools-specific setup.py (which I guess poetry development is also not affected by).

All 3 are part of the general class of "defining 'it works' as pip install poetry exiting successfully".

Look, I'm sure it's a total coincidence and I just have bad luck....

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.