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 >metadata.
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 dpkg-based strategies. 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 also tractable.) >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 >metadata. 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. https://github.com/paulproteus/dirtbike Cheers, -Barry
pgpU53ELnid9R.pgp
Description: OpenPGP digital signature
_______________________________________________ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
