Tastypie's documented requirements and its packaging metadata disagree three times

python-mimeparse gets installed but never appears in the requirements

The core requirements section asks for Python 3.8+, Django 4.2 as an LTS release or Django 4.0 and later including 5.0 and 5.1, and dateutil 2.1 or newer. The packaging metadata installs two packages, not one:

install_requires=[
    'python-mimeparse >= 0.1.4, != 1.5',
    'python-dateutil >= 2.1',
]

So a dependency is hard required at install time and absent from the documented list, which matters most for anyone building an offline bundle or an image from the requirements text alone.

Two more disagreements sit in the classifiers of the same file. They still advertise `Programming Language :: Python :: 2` alongside Python 3.8, and they list Django 5.2, which the requirements section does not mention. The framework support line in the readme stops at 5.1 while the metadata has moved on. Read either one and you are reading a slightly different support matrix than the other promises.

Two dependency lists, one of which drops the exclusion

The same project declares its dependencies twice, in different files, with different constraints:

python-dateutil>=2.1
python-mimeparse>=0.1.4

That is the contents of `requirements.txt`, and it carries no exclusion. The exclusion lives in `install_requires` as `!= 1.5`, which tells you a specific mimeparse release is known to be bad and is worth knowing about if you pin that package yourself.

`setup.py` also keeps the legacy `requires` key alongside `install_requires`, and the old list spells the two packages with underscores rather than hyphens, so the constraints appear twice in one file in two spellings. The version is not written there at all: it is imported from `tastypie.__version__`, which is the sane choice and means the package metadata and the importable module cannot drift apart.

Two other details from that file describe the packaging shape. `zip_safe=False` is set, and `package_data` ships `templates/tastypie/*`, which is how the browsable API templates get into the wheel. The explicit package list includes `tastypie.contrib.gis` and `tastypie.contrib.contenttypes`, so the geospatial and content types integrations are part of the distribution rather than extras.

Four output formats, and the declared test dependencies cover three

JSON is the only format that needs nothing extra. The rest are opt in dependencies: XML needs lxml 3 and defusedxml, YAML needs pyyaml, and binary plist needs biplist, whose project link in that list still points at a bitbucket address. Digest authentication is separate again, through the optional python3-digest package.

The packaging file's `tests_require` names three of them, PyYAML, lxml and defusedxml. Biplist is the format with no entry there, so the plist path is not covered by the declared test dependencies, and neither is the digest authentication path, which lives under Optional rather than Format Support.

The lxml line is also pinned by major version where the others are open ended. Pinning a serializer to a major version from several years ago is a defensible choice for a library promising stable XML output, and it is also a constraint your build has to satisfy rather than something it inherits.

Security reports go to a mailing list address, not to the repository

The security section is short and has one instruction that matters: if you find a hole, do not open a GitHub issue, email `[email protected]` instead. The stated reason is that the maintainers will work with the reporter to investigate and resolve it so a solution can be announced alongside the vulnerability, which is the normal disclosure sequence.

So the private channel is a Google Groups address, and the repository does carry a `SECURITY.rst` file at its root as well. Those are two different routes, and nothing in the readme section points from one to the other or says which one is currently read first.

The framing around it is candid rather than defensive. The project says no software is immune to security holes and that it relies on its community to report and help investigate issues. For an API layer sitting between your database and the internet, that reporting path is part of the adoption decision rather than a footnote.

Help is a StackOverflow tag and an IRC channel, and nothing newer

Two channels are named for getting help: the `tastypie` tag on StackOverflow, and an IRC channel, `#tastypie on irc.freenode.net`, described as a place to get help, bounce an idea by the maintainers, or talk in general.

What is not named is as informative as what is. There is no chat platform of any kind in that list, no discussion forum, no GitHub Discussions, and no mention of the issue tracker as a support route, even though the repository has a `.github/` directory and the project is on a forge that has discussions built in.

The reference material points the same way. Beyond the project's own documentation and a link to the basic usage tests, the list is general REST reading: a Wikipedia page on REST, a Wikipedia list of HTTP status codes, the text of RFC 2616, and a well known blog post on REST worst practices. For a library whose stated reason to exist includes using HTTP well, sending readers to a general reference list is a reasonable default and not a substitute for API level documentation.

The declared homepage is plain http while the doc links are https

The project homepage is recorded as `http://tastypieapi.org/`, without a TLS scheme, while the documentation lives on `django-tastypie.readthedocs.io` over https and the source lives on GitHub. So the one URL a distribution system or a badge generator is likely to pick up first is the one that cannot make a secure request.

The readme is an `.rst` file rather than markdown, and its badge block is written in reStructuredText image directives pointing at a Read the Docs badge, a GitHub Actions workflow badge for python-package.yml, a Coveralls badge for code coverage, and two PyPI badges for version and monthly downloads. Four separate external services appear in the header.

The root of the tree matches that mixture of eras and tools: `setup.py` and `setup.cfg` together, `tox.ini`, `requirements.txt`, `.readthedocs.yaml`, `MANIFEST.in`, a `TODO` file, an `AUTHORS` file, and a file named `BACKWARDS-INCOMPATIBLE.txt`.

The whole basic example is one resource class and one include

The quick start is short enough to read in full:

from tastypie.resources import ModelResource
from myapp.models import Entry

class EntryResource(ModelResource):
    class Meta:
        queryset = Entry.objects.all()

from django.urls.conf import re_path, include
from tastypie.api import Api

v1_api = Api(api_name='v1')
v1_api.register(EntryResource())

urlpatterns = [
    re_path(r'^api/', include(v1_api.urls)),
]

A resource class with a queryset, an Api named `v1`, a registration call and a url include is the entire surface. That gives a read write API with all CRUD operations for the model, with JSON, XML and YAML available without extra configuration.

Two choices in the example are worth noticing. The URL prefix is wired with `re_path` and a regular expression rather than the path converter style, and the api is versioned by name at the `Api` object rather than by a path prefix, so the versioning lives in the registration call. Related data, authentication and caching are described as easy to add rather than configured here.

Version 0.15 with a breaking changes file at the root

The description says creating delicious APIs for Django apps since 2010, and the numbers agree: the newest release is v0.15.1 from 2025-02-23, before it v0.15.0 from 2024-11-20 and v0.14.7 from 2024-04-23. Sixteen years of work and the project is still below 1.0, with a classifier reading `Development Status :: 4 - Beta` and a sentence that it is currently in beta but being used actively in production on several sites.

Being below 1.0 and calling that out is a coherent position rather than a contradiction, but it does interact with a file at the root named `BACKWARDS-INCOMPATIBLE.txt`. A project that does not promise a stable interface still keeps a running record of interface changes, which is the arrangement you want and not the one a version number alone would suggest.

The default branch is `master`, the last push to it is 2026-07-27, and the tree carries `tests/` with a `basic` directory that the readme names as the reference for usage examples. The licence is recorded in the classifiers as an OSI approved BSD licence.

Editorial conclusion

Tastypie earns a place when you want XML treated as a first class output rather than an afterthought, and when you would rather declare a resource class than write a serializer. Two things to check before committing. Read the packaging metadata rather than the requirements section, because the installed dependency set is wider than the documented one and the pinned exclusion of one mimeparse version exists in only one of the two files that list it. And route security reports to the address the project gives rather than opening an issue, while noticing that the channel is a mailing list address and the help channels in the same file are older than the project's current release cadence.

Frequently asked questions

Official sources

1. django-tastypie/django-tastypie on GitHub
2. Issues
3. Project website
4. README
5. Releases