I don't work on any of those packages, but I think your logic makes sense.
> I see that subliminal is currently using the tarballs from PyPI and then
> patching in the source for the nautilus extension which is of course
> absent from there. Also the Github-hosted tarballs include a test suite
> which is not in the PyPI tarballs.
> It seems that the upstream nautilus extension has now moved to a
> different dedicated upstream repo:
> Unfortunately this repository does not seem to have versioned releases,
> and has not seen an update in several months. My thinking is that if we
> continue to provide the nautilus extension at all, it should be built by
> a new source package src:subliminal-nautilus (which could potentially
> also build the nemo extension provided in a different branch of the
> upstream repo) tracking snapshots of the upstream git.
> I am happy to work on this as part of packaging the latest upstream
> release, but I just wanted to check before I do so that:
> 1) the source split I proposed is sensible (if so I'll probably just
> drop the nautilus extension for now and reopen
> https://bugs.debian.org/821455 until I repackage the extension in its
> new home), and
> 2) if the split is ok, which if either Python packaging team would
> make a good home for the nautilus extension, and
> 3) it's ok to change the tarballs to the Github ones and update the
> d/watch accordingly. The point of this would be to be able to run the
> test suite.