On Fri, Jan 15, 2016 at 9:56 PM, Steve Waterbury <water...@pangalactic.us> wrote:
> On 01/15/2016 04:08 PM, Benjamin Root wrote: > >> So, again, I love conda for what it can do when it works well. I only >> take exception to the notion that it can address *all* problems, because >> there are some problems that it just simply isn't properly situated for. >> > > Actually, I would say you didn't mention any ... ;) The issue is > not that it "isn't properly situated for" (whatever that means) > the problems you describe, but that -- in the case you mention, > for example -- no one has conda-packaged those solutions yet. > > FWIW, our sysadmins and I use conda for django / apache / mod_wsgi > sites and we are very happy with it. IMO, compiling mod_wsgi in > the conda environment and keeping it up is trivial compared to the > awkwardnesses introduced by using pip/virtualenv in those cases. > > We also use conda for sites with nginx and the conda-packaged > uwsgi, which works great and even permits the use of a separate > env (with, if necessary, different versions of django, etc.) > for each application. No need to set up an entire VM for each app! > *My* sysadmins love conda -- as soon as they saw how much better > than pip/virtualenv it was, they have never looked back. > > IMO, conda is by *far* the best packaging solution the python > community has ever seen (and I have been using python for more > than 20 years). I too have been stunned by some of the resistance > to conda that one sometimes sees in the python packaging world. > I've had a systems package maintainer tell me "it solves a > different problem [than pip]" ... hmmm ... I would say it > solves the same problem *and more*, *better*. I attribute > some of the conda-ignoring to "NIH" and, to some extent, > possibly defensiveness (I would be defensive too if I had been > working on pip as long as they had when conda came along ;). > Conda and pip solve some of the same problems, but pip also does quite a bit more than conda (and vice et versa, as conda also acts akin rvm-for-python). Conda works so well because it supports a subset of what pip does: install things from binaries. This is the logical thing to do when you want to distribute binaries because in the python world, since for historical reasons, metadata in the general python lang are dynamic by the very nature of setup.py. For a long time, pip worked from sources instead of binaries (this is actually the reason why it was started following easy_install), and thus had to cope w/ those dynamic metadata. It also has to deal w/ building packages and the whole distutils/setuptools interoperability mess. Conda being solely a packaging solution can sidestep all this complexity (which is again a the logical and smart thing to do if what you care is deployment). Having pip understand conda packages is a non trivial endeavour: since conda packages are relocatable, they are not compatible with the usual python interpreters, and setuptools metadata is neither a subset or a superset of conda metadata. Regarding conda/pip interoperability, there are things that conda could (and IMO should) do, such as writing the expected metadata in site-packages (PEP 376). Currently, conda does not recognize packages installed by pip (because it does not implement PEP 376 and co), so if you do a "pip install ." of a package, it will likely break existing package if present. David
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
