Include assets in source tarball #111
Conversation
| @@ -1,4 +1,6 @@ | |||
| recursive-include django_downloadview * | |||
| recursive-include demo *.py *.rst *.html *.json *.txt | |||
There was a problem hiding this comment.
Is this the tests you are talking about?
There was a problem hiding this comment.
I would use it for the tests and possibly provide it as an example inside the Debian package.
There was a problem hiding this comment.
Disclaimer: I'm a newbie in Debian packaging.
First and foremost, I'd appreciate this project being available as a debian package. In order to review the changes, I first need to understand them...
If you need almost all the content of the repository, wouldn't it be simpler to clone the repository? How is the debian package generated?
I would use it for the tests
At the moment, I don't understand the purpose of such tests. Can you explain it? Or perhaps provide an URL where I could learn about it?
Demo and tests contain stuff that is about the project's development. This stuff can be quite big (data inside). And I'd like users to download only what they actually need... At the moment, demo and tests are excluded from the Python distribution. Would users need demo and tests when they install the debian package?
Note: there is a django_downloadview.test included in the package, as a library to write tests around user-custom views created using django-downloadview.
There was a problem hiding this comment.
The base from which the package is generated is a tarball. The is a tool called uscan that is used to scan for new upstream releases. I could use the git repo but in the end I would still need it to generate a tarball that can can be uploaded to the Debian archive. Therefore having python setup.py sdist generate a complete tarball is usually the easiest way. Additionally if I would just clone your repo to create the tarball I would also have to take care about excluding files like .gitignore and the like that have no place in a proper source tarball.
The tests are run when someone (usually a Debian Developer or Debian Maintainer) builds the package from the source tarball. This is considered best-practice if tests are available from upstream. Plus, those tests, if included in the tarball and wired up in the Debian packaging code are run constantly by the Debian CI to check for regression in the package or its dependencies.
If you want to learn about packaging for Debian, a good starting point is the Debian Wiki.
fladi
force-pushed
the
include_assets
branch
from
b604fa5
to
71fa40c
Compare
|
FYI, the Debian package is ready: |
It would be nice to have tests and documentation sources included in the source tarball on PyPI. Also, it is not necessary to explicitly include the main Python package in MANIFEST.in as
packages=[…]already accounts for this.This would also be a nice addition for the Debian package that I'm working on so I can build the documentation and ship it there plus I would be able to run the tests during build to scan for regressions inside Debian.