On 1 December 2013 19:21, Marcus Smith <qwc...@gmail.com> wrote: >>> sometimes mean needing to build components with external dependencies >>> from source > > you mean build once (or maybe after system updates for wheels with external > binary deps), and cache as a local wheel, right?
Note that it is possible to convert binary packages from other formats to wheel. We already support egg and bdist_wininst. If conda has built packages that are worth supporting, I doubt that a conda-to-wheel converter would be hard to write. I'd be willing to write one if someone can point me at a spec for the conda package format (I couldn't find one from a brief look through the docs). Conversely, if I have a wininst installer, a wheel or an egg, is there a converter to conda format? I can't see having to use conda for some things and pip for others as being a move towards lessening user confusion. I see conda (and enthought) as more like distributions - they sit in the same space as rpms and debs. I don't see them as alternatives to pip. Am I wrong? After all, both conda and enthought supply Python interpreter builds as well as package repositories. And both feel like unified ecosystems (you manage everything Python-related with conda) rather than tools like pip (that works with existing Python standards and interoperates with easy_install, distutils, etc). If the issue is simply around defining compatibility tags that better describe the various environments around, then let's just get on with that - we're going to have to do it in the end anyway, why temporarily promote an alternative solution just to change our recommendation later? Paul _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig