On Sat, May 16, 2015 at 4:16 PM, Donald Stufft <don...@stufft.io> wrote:
> On Sat, May 16, 2015 at 3:03 PM, Donald Stufft <don...@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 here: 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.... -Chris -- Christopher Barker, Ph.D. Oceanographer 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.bar...@noaa.gov
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
