4 ms·
This isn't the issue. Wheels and Conda are almost completely orthogonal. Conda is a higher level abstraction than pip. Wheels is operating at the lowest level
by dvanduzer 11y ago
This isn't the issue.
Wheels and Conda are almost completely orthogonal. Conda is a higher level abstraction than pip. Wheels is operating at the lowest level of abstraction.
Multiple package management tools are relatively fine. Having multiple competing format standards (egg vs wheel vs lots of other options) would be a disaster.
(For reference, there's .deb versus .rpm, but also dpkg versus apt-get versus yum versus up2date versus...)
- shoo 11y agoFrom a continuum.io blog post about Conda [1]: > Having been involved in the python world for so long, we are all aware of pip, easy_install, and virtualenv, but these tools did not meet all of our specific requirements. The main problem is that they are focused around Python, neglecting non-Python library dependencies, such as HDF5, MKL, LLVM, etc., which do not have a setup.py in their source code and also do not install files into Python’s site-packages directory. I haven't used Conda, but I totally get their main point here. Python packages sometimes depend upon non-Python packages. Any Python-specific packaging solution that cannot express that e.g. a Python package depends upon a native library does not really solve this problem. I don't regard packaging, dependency management, and isolation as programming-language-dependent problems. [1] http://www.continuum.io/blog/conda http://www.continuum.io/blog/conda
- dvanduzer 11y agoI haven't evaluated Conda either, but the wheel vs egg distinction is categorically different from managing build chains for huge tools like Hadoop.
- ngoldbaum 11y agoReplace "sometimes" with "nearly always" in the scientific world.
- IanOzsvald 11y ago+1 that conda solves "most of our packaging problems" in the science/data science world (I've lived within it for 1.5 years, it really simplifies things). I use conda on Linux, Mac and Windows for r&d and deployment for tools including numpy, sklearn, matplotlib along with flask, pymongo etc.
- e12e 11y agoConda certainly sounds ambitious -- but I'm doubtful how useful it really is. As I see it, it mainly fills two needs: the lack of a package manager on OS X and the lack of a package manager on Windows. Windows is getting a package manager now, and OS X arguably have the App Store. Everywhere else (read: Linux/BSD) -- most of what's packaged by Conda, is already packaged by the vendor. In short: I don't think it's the best way forward (but it may very well be the best way for many usecases/users right now and in the near future).
- shoo 11y agoI agree. There's probably also some element of "it isn't the best general solution, but it's super convenient for some particular group of people, e.g. python users".
- cossatot 11y agoA big part of Conda's usefulness is not system-wide package management a la apt or yum or whatever, but being able to have reproducible, isolated environments for scientific computing or other times when reproducibility is very important, and/or when you need multiple versions of packages for compatibility with other packages. I believe it uses virtualenv for this, but I may be wrong. Regardless, having this feature (as well as no interference with the system Python) is one of the killer features for me, and others I'm sure.
- e12e 11y agoThis is a great point. Still, whole system snapshots in the form of a vm disk image, vagrant etc might be a better way to serve that use-case. Perhapssome form of appkiance levering something like guix or coreOS?
- cossatot 11y agoAn additional benefit of Conda is that building or installing packages that require a C/Fortran compiler can be done without using sudo. This is really nice when you're working on a cluster or other shared computer resources, and don't want to have to bother the sysadmin.