<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 18, 2015 at 9:05 AM, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><p dir="ltr"><br>
On 18 May 2015 07:32, "Chris Barker" <<a href="mailto:chris.barker@noaa.gov" target="_blank">chris.barker@noaa.gov</a>> wrote:<br>
><br>
> On Sun, May 17, 2015 at 12:05 AM, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>> wrote:<br>
>><br>
>> >   % pip install --upgrade pip<br>
>> >   % pip install some_conda_package<br>
>><br>
>> This gets the respective role of the two tools reversed - it's like my<br>
>> asking for "pip install some_fedora_rpm" to be made to work.<br>
><br>
><br>
> 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>
><br>
> 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>
><br>
> 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>
><br>
> Continuum has a bunch of smart people, though.<br>
><br>
>> However, having conda use "pip install" in its build scripts so that<br>
>> it reliably generates pip compatible installation metadata would be a<br>
>> possibility worth discussing - that's what we've started doing in<br>
>> Fedora, so that runtime utilities like pkg_resources can work<br>
>> correctly.<br>
><br>
><br>
> 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>
><br>
> But I'm confused as to the roles of pip vs setuptools, vs wheel, vs ???<br>
><br>
> I see pip has handling the dependency resolution, and finding and downloading of packages part of the problem -- conda does those already.<br>
><br>
> So what would using pip inside a conda build script buy you that using setuptools does not?</p>
</span><p dir="ltr">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/" target="_blank">https://www.python.org/dev/peps/pep-0376/</a> compliant metadata by default.</p></blockquote><div><br></div><div>Note that some packages will push hard against injecting setuptools, at least until it does not offer a way to prevent from installing as an egg directory. Most of the core scientific packages avoid setuptools because of this.</div><div><br></div><div>David</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p dir="ltr">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">Cheers,<br>
Nick.</p>
<br>_______________________________________________<br>
Distutils-SIG maillist  -  <a href="mailto:Distutils-SIG@python.org">Distutils-SIG@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/distutils-sig" target="_blank">https://mail.python.org/mailman/listinfo/distutils-sig</a><br>
<br></blockquote></div><br></div></div>