tests not in pypi sdist

[dvzrv]

Hi! I'm packaging django-rest-framework for Arch Linux.
We usually use pypi as upstream for tracking updates and building from source.

It would be really cool, if the tests were available in the sdist tarball on pypi. Thanks!

Checklist

• I have verified that that issue exists against the master branch of Django REST framework.
• I have searched for similar issues in both open and closed tickets and cannot find a duplicate.
• This is not a usage question. (Those should be directed to the discussion group instead.)
• This cannot be dealt with as a third party library. (We prefer new functionality to be in the form of third party libraries where possible.)
• I have reduced the issue to the simplest possible case.
• I have included a failing test as a pull request. (If you are unable to do so we can still accept the issue.)

Steps to reproduce

• Download the sdist tarball from pypi.
• Build: python setup.py build
• Run pytest

Expected behavior

Be able to run pytest on the build, when using the sdist on pypi.

Actual behavior

Not being able to run the tests.

[lovelydinosaur]

I'd probably prefer we don't package the tests in with the distribution.

[dvzrv]

@tomchristie thanks for getting back to me.

Hm, I don't quite understand. Why would you not want to have the ability to test the sources, that are being provided through pypi.org? What is the rationale behind your decision?

If it were wheel packages, I'd really understand, but for sources this ensures, that whoever is trying to build and install django-rest-framework is able to run unit tests and ensure, that everything is working with the environment it will be installed into.

[lovelydinosaur]

I don't have an strong feeling either way on it, but it's not a massivly widely adopted choice as far as I can see.

Downsides would be that it'd add a bunch of download size, and would almost never be used by end users.

I don't recall having it requested in the ~10 years that REST framework has been around, so doesn't feel like a particularly pressing bit of extra work for us to take on.

[dvzrv]

Hm, maybe I'm just overly optimistic in regards to whether end users actually ever run unit tests on their side, too? :D

Looking at the data, it's roughly 1mb. I guess that's okay, given the fact that most people probably use the wheel when installing via pip anyways.

$ du -hd1 django-rest-framework

988K    django-rest-framework/tests
3.6M    django-rest-framework/rest_framework
20K     django-rest-framework/requirements
8.0K    django-rest-framework/licenses
344K    django-rest-framework/docs_theme
8.7M    django-rest-framework/docs
4.0K    django-rest-framework/.github
47M     django-rest-framework/.git
60M     django-rest-framework

I can open a pull request for this. The increase in size is negliable:

Without tests:

-rw-r--r--  1 dave dave 782K Jan 15 14:52 djangorestframework-3.11.0.tar.gz

With tests:

-rw-r--r--  1 dave dave 802K Jan 15 14:54 djangorestframework-3.11.0.tar.gz

It basically boils down to a oneline patch for MANIFEST.in:

diff --git i/MANIFEST.in w/MANIFEST.in
index 6f7cb8f1..262e3dc9 100644
--- i/MANIFEST.in
+++ w/MANIFEST.in
@@ -1,5 +1,6 @@
 include README.md
 include LICENSE.md
+recursive-include tests/* *
 recursive-include rest_framework/static *.js *.css *.png *.ico *.eot *.svg *.ttf *.woff *.woff2
 recursive-include rest_framework/templates *.html schema.js
 recursive-include rest_framework/locale *.mo

[dvzrv]

As mentioned in #7877 not all test files ended up in the sdist on pypi.org after my change to MANIFEST.in.

In the aforementioned pull request I propose a simplification of the MANIFEST.in file (which only affects the sdist tarballs), so that the file will only include:

prune docs
prune docs_theme
global-exclude *.py[co]

This way all relevant files end up in the sdist tarball, while excluding the docs/ and docs_theme/.

As this change is not deemed useful I will use the (larger) auto-generated source tarballs from github to build the package for Arch Linux from now on.

@tomchristie Feel free to revert my change or incorporate the above change. I will not contribute to this project any further.