This is more of a general question about workflow than perhaps a detailed bug report. This has happened to me three times: I download Anaconda, work with it beautifully, perhaps installing one or two additional packages, but mostly working with Jupyter and Scipy/Numpy/Matplotlib. Then one day conda updates itself to next release (4.0 -> 4.1, or 4.0 ->4.2 depending on the machine) and all goes suddenly wrong. Should I refrain from using conda update and reinstall Anaconda from scratch? Is this a known issue? Is there another procedure or routine I should use, such as updating every few weeks?
It may be that certain other packages(dependencies) need to be updated as well.
conda update conda
conda update anaconda
You can also prevent conda from automatically updating by adding the following to your .condarc file(should be where you installed Anaconda or your user directory and it may be hidden)
auto_update_conda: False
Related
pandoc-crossref must match the pandoc version, and also only the 3.10.0 release works on OSX Big Sur. Thus, it is not possible to get pandoc and pandoc-crossref running in a conda environment from the official channel or from conda-forge.
I could easily download the matching binaries from https://github.com/lierdakil/pandoc-crossref/releases/tag/v0.3.10.0 and copy them e.g. to the binpath:
$ which pandoc-crossref
/usr/local/bin/pandoc-crossref
$ curl -OL https://github.com/lierdakil/pandoc-crossref/releases/download/v0.3.10.0/pandoc-crossref-macOS.tar.xz
$ tar -xzvf pandoc-crossref-macOS.tar.xz
$ mv pandoc-crossref /usr/local/bin/pandoc-crossref
But I think that is not a clean approach, because conda will not know that I updated the version for pandoc-crossref.
What is a clean approach for updating a package managed by conda from a binary available on Github?
Update Feedstock
I updated it on the Conda Forge feedstock, which is what I regard as the "cleanest" solution.
How does one do that? First, OP had posted a comment on the feedstock in the PR that they wanted merged. This was the appropriate first step and hopefully in future cases that should be sufficient to prompt maintainers to act. In this case, it was not sufficient. So, as a follow up, I chatted on the Conda Forge Gitter to point out that the feedstock had gone stale and had non-responding maintainer(s). One of the core Conda Forge members suggested I make a PR bumping the version and adding myself as maintainer, and they merged it for me. In all, this took about 10 mins of work and ~2 hours from start to having an updated package on Anaconda Cloud.
Custom Conda Build
Otherwise, there isn't really a clean solution for non-Python packages outside of building a Conda package. That is, clone the feedstock or write a new recipe, modify it to build from the GitHub reference, then install that build into your environment. It may also be worth uploading to an Anaconda Cloud user account, so there is some non-local reference for it.
Pip Install (Python Packages Only)
In the special case that it is a Python package, one could dump the environment to YAML, edit to install the package through pip, then recreate the environment.
I have installed WinPython and want to use Spyder. I use pip and virtual environments. I have followed the instructions here modular approach. Everything works just dandy until the very last instruction "Start a new IPython console (in Spyder). All packages installed in your venv environment should be available there.".
It get error Your Python environment or installation doesn't have the spyder‑kernels module or the right version of it installed (>= 1.9.0 and < 1.10.0). Without this module is not possible for Spyder to create a console for you.
But I installed spyder-kernals in my venv, I can literally see them there, I set the path the the python installed in the venv, everything should work, but it doesn't!
Any thoughts?
I asked CAM Gerlach as suggested, and he spotted my error very quickly. The instructions at modular approach are correct except they say pip install spyder-kernels==0.* which I took literally. In fact as per the error message you need to use later versions, so I used pip install spyder-kernels==1.10 and it fixed it.
You may have to ask to "C.A.M. Gerlach" if he has an update on the procedure: Spyder has evolved a bit with Spyder-4.
>wsl -l
Windows Subsystem for Linux Distributions:
Ubuntu-18.04 (Default)
Ubuntu
I made the mistake of setting up everything in the Ubuntu-18.04 version, which is locked to that specific version and doesn't allow dist upgrades (Please prove me wrong). This includes shell customizations, symlinks etc.
I would however like to upgrade Ubuntu every once in a while. What I do not want to do is manually find all the configuration files and copy them to the new distribution.
The Ubuntu distribution is the one from the Windows store; fresh clean with no modifications.
How do I get my data from the old distribution into the fresh Ubuntu store distribution? Or is there a way to upgrade the locked Ubuntu-18.04 distribution (also from the Windows store)?
I know of wsl --export and wsl --import, but as far as I can tell these keep the distribution (with in this case the lack of upgrades) and just place a copy of that distribution into another folder. Which does not solve the dist upgrade problem.
I ended up using the free, legacy version of Aptik (I couldn't get the GTK version to launch). Even though it's no longer maintained, it's still working perfectly well, and only took me a single command to export everything and another single command to import everything again.
Debian Jessie, as well as sid, have a mercurial-git package which contains the hg-git plugin. However, this package was (auto-)removed from Debian Stretch to to a release-critical bug.
But - I need it installed and running. Surely this should be possible, right?
Well, I followed the installation instructions on the plugin page:
I ran apt-get install python-setuptools python-setuptools-git python4-setuptools python3-setuptools-git
I ran easy_install hg-git and it seemed to work
But still, when I run various mercurial operations I get, as the first line, the error message:
*** failed to import extension hgext.git: No module named git
(regardless of whether I'm doing anything git-related or not.)
My questions:
Why is this happening?
What do I need to do in order to make the error message go away while having hggit working?
Now,
How do I correctly install dulwich to get hg-git working on Windows?
Apparently, that critical bug doesn't manifest always (and perhaps only under very specific circumstances), so you can try installing the Debian sid version of the mercurial-git package (that is, version 0.8.11-1 at the time of writing). There's a SuperUser question about how to do this:
https://linuxaria.com/howto/how-to-install-a-single-package-from-debian-sid-or-debian-testing
my personal opinion in this case is to simply install the .deb file, which you can get from here (it's not platform-specific; at the link you'll need to choose a mirror.) That makes the error message go away, at least assuming you have:
[extensions]
hgext.bookmarks =
hggit =
in your ~/.hgrc file.
I installed virtualenv + virtualenvwrapper via virtualenv-burrito. However, it seems to be giving me problems now in uninstalling packages from my virtualenvs (case in point, distribute).
It seems that the distribute used by my virtualenvs is the one at /home/skrd/.venvburrito. If, inside a virtualenv, I try to upgrade distribute, it installs to /home/skrd/.virtualenvs but the virtualenv itself is still using the one at /home/skrd/.venvburrito. With that, the packages needing an updated distribute still won't work.
See,
(test)$ $ pip uninstall distribute
Not uninstalling distribute at /home/skrd/.venvburrito/lib/python/distribute-0.6.27-py2.7.egg, outside environment /home/skrd/.virtualenvs/test
I've tried renaming the .venvburrito directory (equivalent to deleting it, but with back-up) but that breaks my virtualenvs. How do I uninstall packages now?
I still don't understand what happened here but I just had the idea to check what's installed for my system's Python outside virtualenv. There I saw distribute, with a similar version to the one that's giving me problems inside a virtualenv.
I upgraded the non-virtualenv installation of distribute and, next time I checked in my virtualenv, the distribute installation has also upgraded.
(So, yes, I'm aware that my question's original intent is to remove distribute. But that was just an intermediary step to updating it---the update was unable to proceed since it can't remove the distribute currently installed. So, there, problem solved.)