[Distutils] Making pip and PyPI work with conda packages

Chris Barker chris.barker at noaa.gov
Sun May 17 02:50:30 CEST 2015

On Sat, May 16, 2015 at 4:16 PM, Donald Stufft <donald at stufft.io> wrote:

> On Sat, May 16, 2015 at 3:03 PM, Donald Stufft <donald at stufft.io> wrote:
>> There are a few other benefits, but that’s not anything that are inherent
>> in the two different approaches, it’s just things that conda has that pip
>> is planning on getting,
> Huh? I"'m confused -- didn't we just have a big thread about how pip+wheel
> probably ISN'T going to handle shared libs -- that those are exactly what
> conda packages do provide -- aside from R and Erlange, anyway :-)
> but it's not the packages in this case that we need -- it's the
> environment -- and I can't see how pip is going to provide a conda
> environment….
> I never said pip was going to provide an environment, I said the main
> benefit conda has over pip, which pip will most likely not get in any
> reasonable time frame, is that it handles things which are not Python
> packages.

well, I got a bit distraced by Erlang and R -- i.e. things that have
nothing to do with python packages.

libxml, on the other hand, is a lib that one might want to use with a
python package -- so a bit more apropos here.

But my confusion was about: "things that conda has that pip is planning on
getting" -- what are those things? Any of the stuff that conda has that
really useful like handling shared libs, pip is NOT getting -- yes?

> A shared library is not a Python package so I’m not sure what this message
> is even saying? ``pip install lxml-from-conda`` is just going to flat out
> break because pip won’t install the libxml2 shared library.

exactly -- if you're going to install a shared lib, you need somewhere to
put it -- and that's what a conda environment provides.

Trying not to go around in circles, but python _could_ provide a standard
place in which to put shared libs -- and then pip _could_ provide a way to
manage them. That would require dealing with that whole binary API problem,
so we probably won't do it. I'm not sure what the point of contention is

I think it would be useful to have a way to manage shared libs solely for
python packages to use -- and it would be useful to that way to be part of
the standard python ecosytem. Others may not think it would be useful
enough to be worth the pain in the neck it would be.

And that's what the nifty conda packages continuum (and others) have built
could provide -- those shared libs that are built in a  compatible way with
a python binary. After all, pure python packages are no problem, compiled
python packages without any dependencies are little problem. The hard part
is those darn third party libs.

conda also provides a way to mange all sorts of other stuff that has
nothing to do with python, but I'm guessing  that's not what continuum
would like to contribute to pypi....



Christopher Barker, Ph.D.

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20150516/66d232ad/attachment.html>

More information about the Distutils-SIG mailing list