On Apr 28, 2017, at 11:50 AM, Nick Coghlan wrote:
My recollection from the last time I looked at this was that where
rewheel assumes that the Python level PEP 376 package metadata will be
available, dirtbike instead queried the operating system level
dirtbike consults a list of "strategies" of which the PEP 376 metadata
strategy is the top priority. If that fails, then it does fall back to
Why might the PEP 376 strategy fail? There are cases in Debian where we split
upstream source packages into multiple binary packages. So for example,
the pkg_resources binary package is separate from setuptools, so if we want to
rewheel pkg_resources, there won't be PEP 376 metadata associated with it.
All of the existing fall back strategies exist to handle real-world corner
cases. The intent (if not the reality, 'cause it hasn't been done yet ;) is
that dirtbike is extensible for systems where different fall backs would be
necessary. But if the PEP 376 metadata can be found, and it provides what's
needed, that would be good enough.
(Some of the testing framework is probably Debian-centric, but I think that's
The biggest benefit I see to the dirtbike approach is that it has the
potential to work with Python bindings that aren't built with the
standard Python packaging tools, and hence don't have any PEP 376
Yep, and it should be adaptable to finding that non-standard metadata by
consulting any alternative system databases.
Conversely, the biggest benefit I see to the rewheel approach is that
it lets system packages more clearly indicate whether or not they want
to support rewheel by including or omitting the PEP 376 metadata.
I should also mention that according to Debian policy, we're tightly focused
on rewheeling just the small number of packages to make pip and
virtualenv/venv work. Not that it couldn't be used for other things, just
that only those dependencies are allowed to ship .whl files in debs.