3 ms·
> Not a fan of Conda, the cli is terrible, their unofficial builds are opaque and in my experience the very few packages that are not available on pypi are rare
by ihnorton 7y ago
> Not a fan of Conda, the cli is terrible, their unofficial builds are opaque and in my experience the very few packages that are not available on pypi are rarely worth installing (usually the worst kind of "research code"[1]).
The CLI used to be slow, but since 4.6 the performance is reasonable -- still slower than some non-Python package managers, but in my experience no longer so slow as to be aggravating (< 10s install now, whereas previously >30-60s in the past just solving the environment)
> their unofficial builds are opaque
I'm not entirely sure what builds you are referring to, but conda-forge [1] is completely open source and community-driven, and Anaconda recipes are in a github organization called AnacondaRecipes [2]. If you are talking specifically about the Python interpreter builds for the Anaconda distribution, I believe the build recipes are here [3] (although I don't know that for a fact).
> my experience the very few packages that are not available on pypi are rarely worth installing
Depending on your field, platform, and dependencies, that is certainly believable. However, several projects such as Apache Arrow and Rapids have dropped support for PyPI wheels [4] because the engineering cost of wheel-building on linux is prohibitive, and conda is preferable on windows for a variety of reasons.
> usually the worst kind of "research code"[1]
That's an oddly-specific complaint. Anyway, given the variety of environments where people run `setup.py`, that kind of thing is usually explained by "someone put in a PR to make it build somewhere." It might be surprising if you've never built or packaged python extensions with native dependencies before, but I'm not sure it's a particular indicator of quality.
[1] https://conda-forge.org/ https://conda-forge.org/
[2] https://github.com/AnacondaRecipes https://github.com/AnacondaRecipes
[3] https://github.com/AnacondaRecipes/python-feedstock https://github.com/AnacondaRecipes/python-feedstock
[4] https://medium.com/rapids-ai/rapids-0-7-release-drops-pip-packages-47fc966e9472 https://medium.com/rapids-ai/rapids-0-7-release-drops-pip-pa...
- orf 7y ago> their unofficial builds are opaque By opaque I mean: https://github.com/AnacondaRecipes/tensorflow_recipes/tree/master/tensorflow-base-cpu https://github.com/AnacondaRecipes/tensorflow_recipes/tree/m... What do these do. Why are they adding an alternative gettime implementation for MacOS? Why are they patching a bunch of test files to make them pass? > That's an oddly-specific complaint. It's unfortunately one we ran into recently while migrating a legacy system off conda, but it's not the first and I doubt it will be the last.
- ihnorton 7y ago> What do these do. Why are they adding an alternative gettime implementation for MacOS? Why are they patching a bunch of test files to make them pass? The gettime patch is to support macOS SDK < 10.12, as it says in the patch itself. From a quick look, some of the test patches appear to be for Python 2 compatibility. Every linux distribution and system integrator has a patch list just like that for complicated software. If a particular patch concerns you, I would suggest opening an issue on their bug tracker to ask for an explanation. > It's unfortunately one we ran into recently while migrating a legacy system off conda, but it's not the first and I doubt it will be the last. Unclear what that has to do with conda. The same package is available on PyPI (source only), and the line you highlighted almost certainly exists for some other build target than conda, where the compilers will automatically find numpy includes in CONDA_PREFIX without any extra effort.