<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On May 17, 2015, at 8:12 PM, Robert Collins <<a href="mailto:robertc@robertcollins.net" class="">robertc@robertcollins.net</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><p dir="ltr" class=""><br class="">
On 17 May 2015 5:05 pm, "Nick Coghlan" <<a href="mailto:ncoghlan@gmail.com" class="">ncoghlan@gmail.com</a>> wrote:<br class="">
><br class="">
><br class="">
> On 18 May 2015 07:32, "Chris Barker" <<a href="mailto:chris.barker@noaa.gov" class="">chris.barker@noaa.gov</a>> wrote:<br class="">
> ><br class="">
> > On Sun, May 17, 2015 at 12:05 AM, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com" class="">ncoghlan@gmail.com</a>> wrote:<br class="">
> >><br class="">
> >> > % pip install --upgrade pip<br class="">
> >> > % pip install some_conda_package<br class="">
> >><br class="">
> >> This gets the respective role of the two tools reversed - it's like my<br class="">
> >> asking for "pip install some_fedora_rpm" to be made to work.<br class="">
> ><br class="">
> ><br class="">
> > I agree here -- I was thinking there was some promise in a conda_package_to_wheel converter though. It would, of course, only work in a subset of conda packages, but would be nice.<br class="">
> ><br class="">
> > The trick is that conda packages for the hard-to-build python packages (the ones we care about) often (always?) depend on conda packages for dynamic libs, and pip+wheel have no support for that.<br class="">
> ><br class="">
> > And this is a trick, because while I have some ideas for supporting just-for-python dynamic libs, conda's are not just-for-python -- so that might be hard to mash together.<br class="">
> ><br class="">
> > Continuum has a bunch of smart people, though.<br class="">
> ><br class="">
> >> However, having conda use "pip install" in its build scripts so that<br class="">
> >> it reliably generates pip compatible installation metadata would be a<br class="">
> >> possibility worth discussing - that's what we've started doing in<br class="">
> >> Fedora, so that runtime utilities like pkg_resources can work<br class="">
> >> correctly.<br class="">
> ><br class="">
> ><br class="">
> > Hmm -- that's something ot look into -- you can put essentially anything into a conda bulid script -- so this would be a matter of convention, rather than tooling. (of course the conventions used by Continuum for the "offical" conda packages is the standard).<br class="">
> ><br class="">
> > But I'm confused as to the roles of pip vs setuptools, vs wheel, vs ???<br class="">
> ><br class="">
> > I see pip has handling the dependency resolution, and finding and downloading of packages part of the problem -- conda does those already.<br class="">
> ><br class="">
> > So what would using pip inside a conda build script buy you that using setuptools does not?<br class="">
><br class="">
> Indirection via pip injects the usage of setuptools even for plain distutils projects, and generates <a href="https://www.python.org/dev/peps/pep-0376/" class="">https://www.python.org/dev/peps/pep-0376/</a> compliant metadata by default.<br class="">
><br class="">
> However, looking at the current packaging policy, I think I misremembered the situation - it looks like we *discussed* recommending indirection via pip & attaining PEP 376 compliance, but haven't actually moved forward with the idea yet. That makes sense, since pursuing it would have been gated on ensurepip, and the Python 3 migration has been higher priority recently.</p><p dir="ltr" class="">That glue is actually very shallow...I think we should rip it out of pip and perhaps put it in setuptools. It's about building, not installing.</p></div></blockquote></div><div class=""><br class=""></div><div class="">So a benefit of using pip instead of setuptools is that as we move to a pluggable build system pip can act as a unified fronted to multiple build systems, instead of every system having to implement each pluggable build system themselves.</div><br class=""><div class="">
<div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">---</div><div class="">Donald Stufft</div><div class="">PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA</div></div></div>
</div>
<br class=""></body></html>