One fairly fundamental problem here is that pip is used for multiple purposes: If pip usage is indeed warranted, it should be done once - any further updates require recreating the environment for reliable results (as documented under “Recreate the environment if changes are needed” in this section of the conda docs).
Anaconda create environment from requirements.txt install#
no-build-isolation.Īnother thing that leads to unpredictable results is iterative use of conda install and pip install in an environment - this tends to degrade and then break. Even advanced Python users who are comfortable building from source tend to shoot themselves in the foot because they use pip install. The Spyder team even made a polished 3-minute video about this with the usual “avoid mixing pip and conda” advice. This is a very frequent source of broken environments and of bug reports to popular Python packages. On the other hand, pip is often misused (especially by beginning users) when conda or mamba should be used instead. Unlike most conda features, this doesn’t seem to have an analog in mamba (it’s possible that mamba already has the improved behavior hidden behind this flag, not sure).
pip list and pip check are used too: Guidelines - conda-forge 2023.02.09 documentation.Another example: Contributing packages - conda-forge 2023.02.09 documentation.vv, as documented in Contributing packages - conda-forge 2023.02.09 documentation, recipe/build.sh in a conda-forge feedstock is likely to contain something like $ -m pip install.As part of the workflow for building conda packages:.Using an all-wheel workflow like conda create -n my-devenv python=3.11 (which does install pip in addition to python 3.11) followed by pip install a-bunch-of-pypi-pkgs,.This can be a development version of any package, even if it’s available as a release in a conda channel, Installing a package from source locally.Installing Python packages from PyPI for which no conda package is available in defaults, conda-forge or another channel,.There are multiple reasons for users or tools wanting to use pip or wheels from PyPI inside a conda environments: I’ll note that the question is broader than pip - there are other Python package installers, and there are also topics like virtual environments and dependency specifiers that interact with conda/ mamba or conda environments. This may, but doesn’t have to, include a request for new features from pip or from Python packaging. That is not an easy question, but it would be great to see a coherent view indeed. Rather than always pushing back with “this doesn’t work for conda”, Steve Dower suggested that the conda community should specify how it wants pip to behave inside conda envs (see ).
This post specifically outlines the existing “knobs” available for tweaking how pip interacts with other package managers.PEP 668 - Marking Python base environments as “externally managed” (a bit older).The Python Packaging Strategy Discussion - Part 1 thread.The Wanting a singular packaging tool/vision thread.PEP 704 - Require virtual environments by default for package installers, which proposes a change which would be a significant backwards compat break in pip for conda users.Over the past few months there have been a number of threads on the Python packaging Discourse where Conda came up. There are both legitimate needs for using Pip in a Conda environment and easy to make mistakes by users which break environments or applications when they are using pip when then should have used conda or mamba. There is a long history of discussions around, and issues with, the use of Pip in Conda environments.
0 kommentar(er)
