#CONDA UPGRADE PACKAGE INSTALL#
If you use pip -user install in the latter environment those packages are still picked up by the former environment.Īnaconda was the main way that our users (which had a very wide range of technical backgrounds) got access to Python, and they weren’t allowed to install software manually, so some users were always going to use Spyder via Anaconda to do their work. The problem is that you may only install packages via conda in one conda environment but in another conda environment you might be using conda to just bootstrap Python and use pip install to install everything else. It could have happened with any package installed with conda, Spyder was just more likely to break due to have more dependencies. Thanks for the advise but this wasn’t really about Spyder, as Spyder breaking was a symptom of pip -user installs being fundamentally incompatible with using conda to manage your Python environments. In addition to our stable pynsist and py2app based ones, we now have new experimental conda-based installers for all three major platforms, which will allow for auto-updating, installing Spyder plugins and creating/modifying user environments all in a controlled manner, combining the benefits of both a conda and a standalone install while opening the door to adding package, environment and plugin management functionality right within Spyder. We also advising that if they do install Spyder with Anaconda, they use a separate isolated env instead of base.
#CONDA UPGRADE PACKAGE HOW TO#
I haven’t personally seen that too much, but our other developers have seen that happen, so we specifically mention it and how to fix it in some of our tutorial/help videos.Īlso, just FYI, it is for reasons like this that we’ve been recommending our standalone installers to avoid the many issues with users doing all sorts of ill advised things like this and breaking Spyder. But thought people might be interested in a real world example.Ī user would pip install something, pip would default to user install because the base directory is read only, and then all of a sudden their Spyder installation would no longer work. And it was my opinion that because we controlled the environment and had specific needs it wasn’t worth bringing up or arguing it should be default. The solution was fairly easy though, we updated the default pip.ini we distributed with the Anaconda install to include a user=false flag (forget the specific config). A user would pip install something, pip would default to user install because the base directory is read only, and then all of a sudden their Spyder installation would no longer work. The problem was that pip -user install is fundamentally at odds with conda environments, and would often break even the base environment. I have some real world experience of this causing issues, I managed an Anaconda distribution at a large enterprise and for technical and cultural reasons it made sense to make the base install of Anaconda read-only and users who wanted Python with other packages could use venv or conda to create their own environments. I personally have no particular stake in the current behaviour, it was designed mainly to handle the concerns of Unix users and distro maintainers, where the ergonomics may be different.
#CONDA UPGRADE PACKAGE FREE#
But that’s getting a bit out of scope here…įeel free to raise an issue on pip proposing a better behaviour.
conda (and I typically run pip with -dry-run first for that reason, despite it taking twice the time and effort). That would have avoided the overwhelming majority of issues (on different platforms and on both *conda and ) I’d ran into where an environment got screwed up due to either user error (installing in the wrong env, wrong interpreter, with/without sudo, the wrong spec, or some other issue) or packaging issues, and is the single biggest feature I miss vs.
dry-run, preferably in a more readable format) before doing it and asking for confirmation. Honestly, if it were up to me, now that pip has a solver and dry run support, I’d much rather it act like most package managers (either by default or at least with an option) and display what it is going to do (i.e. I almost always work in venvs, so if I forget to activate one, I’d rather pip fail or prompt than silently install into -user if I don’t deliberately sudo it at least one time this happened, it resulted in a very laborious cleanup and reinstall effort. Personally, when I’m on Linux, I’d especially prefer pip giving an error or prompting for confirmation to fall back to a user install, though for slightly different reasons as on Windows.
0 kommentar(er)
