search

gluap / pyduofern

GNU General Public License v2.0
40 stars 11 forks source link

Source tarball incomplete #23

Closed fabaff closed 4 years ago

fabaff commented 4 years ago

The latest available source tarball from PyPI doesn't contain all files needed to run the tests.

]$ ls -lisa pyduofern-0.34.0/pyduofern/tests/
total 20
5661034 4 drwxr-xr-x. 5 x21 x21 4096 Sep  3 08:47 .
5661033 4 drwxr-xr-x. 3 x21 x21 4096 Sep  3 08:47 ..
5661035 4 drwxr-xr-x. 2 x21 x21 4096 Sep  3 08:47 files
5661036 4 drwxr-xr-x. 2 x21 x21 4096 Sep  3 08:47 recording
5661037 4 drwxr-xr-x. 2 x21 x21 4096 Sep  3 08:47 replaydata
gluap commented 4 years ago

Hi @fabaff,

do you require the tests as part of the pypi tarball or is this just to point out the inconsistency? I'm unsure whether it makes sense to package the tests at all for pypi -- most users won't need them and those who do are likely to use git as soon as they dig in deep enough to run unit tests, so it shouldn't be a problem for these either.

If you have/know of a workflow that advocates it I'll gladly package the replay data as part of the tarball though. Otherwise I'd lean towards fixing it by excluding the tests from packaging altogether.

Cheers, Paul

fabaff commented 4 years ago

During the process of building RPM packages, at least for Fedora, it's recommended to run the tests. End-consumers don't care about tests usually, that's true.

To keep the source for PyPI lean, simply create a release on GitHub by tagging the source. This source tarball contains everything and allows interested parties to run the tests.

gluap commented 4 years ago

@fabaff thank you for the clarification.

I moved the unit tests out of the module so they are not in the python package any more.

As per your suggestion I marked the version as a release in github so the full sources become available as a tarball from and can be used as a reference for packaging.

gluap commented 4 years ago

I guess this is fixed, feel free to reopen if I am wrong.