how to properly remove conda.jl and all configurations

[AbhimanyuAryan]

I want to start fresh. My conda is inside .julia/conda/3(whatever are the defaults). I want to remove conda, all env configurations

How can I do that?

[mkitti]

You could just try moving .julia/conda to .julia/conda_backup, see if everything works, and then delete .julia/conda_backup

[AbhimanyuAryan]

@mkitti thanks almost didn't see this reply in notification :)

[deszoeke]

I am deleting .julia/conda and reinstalling with ENV["PYTHON"]="".

But using PyCall; PyCall.pyimport("numpy") hangs.

Is there any other configuration I need to expunge?

[mkitti]

@deszoeke I recommend starting a new issue.

[stevengj]

You should also do rm(abspath(first(DEPOT_PATH), "conda", "deps.jl"))

(This should really get updated to use the Preferences mechanism from Julia 1.8)

[deszoeke]

For me

abspath(first(DEPOT_PATH), "conda", "deps.jl")
$HOME/.julia/conda/deps.jl

is removed by recursively wiping .julia/conda.

@mkitti > @deszoeke I recommend starting a new issue.
Is the issue of starting conda fresh resolved by wiping .julia/conda (and deps.jl) then?

That would suggest my problem persists even when completely reinstalling conda. Where to file it? It might cut across Conda and PyCall. It manifests at importing python packages, e.g., numpy or matplotlib (PyPlot #567) but I suspect it is upstream of the packages themselves.

[mkitti]

PyCall.jl creates it's own deps.jl within ~/.julia/packages that stores the location of Python. This is generated during Pkg.build(). See the following line.

https://github.com/JuliaPy/PyCall.jl/blob/bcaba00d1e2c412b2f61d33343ef5a9ab1b9258a/deps/build.jl#L103

[deszoeke]

I do not have a ~/.julia/packages/deps.jl

[mkitti]

Search for a deps.jl under ~/.julia/packages/PyCall

$ find ~/.julia/packages/PyCall -iname deps.jl
~/.julia/packages/PyCall/twYvK/deps/deps.jl

$ cat ~/.julia/packages/PyCall/twYvK/deps/deps.jl
const python = "python3"
const libpython = "~/mambaforge-pypy3/envs/mambadev/lib/libpython3.10.so.1.0"
const pyprogramname = ~/mambaforge-pypy3/envs/mambadev/bin/python3"
const pyversion_build = v"3.10.8"
const PYTHONHOME = "~/mambaforge-pypy3/envs/mambadev:~/mambaforge-pypy3/envs/mambadev"

"True if we are using the Python distribution in the Conda package."
const conda = false

[deszoeke]

Interesting. There are lots of residues in packages/PyCall/xxxxx/deps/deps.jl, but none that implicate mamba:

$ find ~/.julia/packages/PyCall -iname deps.jl
~/.julia/packages/PyCall/BD546/deps/deps.jl
~/.julia/packages/PyCall/twYvK/deps/deps.jl
~/.julia/packages/PyCall/7a7w0/deps/deps.jl
$ cat ~/.julia/packages/PyCall/BD546/deps/deps.jl
const python = "~/.julia/conda/3/bin/python"
const libpython = "~/.julia/conda/3/lib/libpython3.7m.dylib"
const pyprogramname = "~/.julia/conda/3/bin/python"
const pyversion_build = v"3.7.11"
const PYTHONHOME = "~/.julia/conda/3:/Users/sdeszoek/.julia/conda/3"

"True if we are using the Python distribution in the Conda package."
const conda = true
$ cat ~/.julia/packages/PyCall/twYvK/deps/deps.jl
const python = "~/.julia/conda/3/bin/python"
const libpython = "~/.julia/conda/3/lib/libpython3.10.dylib"
const pyprogramname = "~/.julia/conda/3/bin/python"
const pyversion_build = v"3.10.10"
const PYTHONHOME = "~/.julia/conda/3:/Users/sdeszoek/.julia/conda/3"

"True if we are using the Python distribution in the Conda package."
const conda = true
$ cat ~/.julia/packages/PyCall/7a7w0/deps/deps.jl
const python = "~/.julia/conda/3/bin/python"
const libpython = "~/.julia/conda/3/lib/libpython3.7m.dylib"
const pyprogramname = "~/.julia/conda/3/bin/python"
const pyversion_build = v"3.7.11"
const PYTHONHOME = "~/.julia/conda/3:/Users/sdeszoek/.julia/conda/3"

"True if we are using the Python distribution in the Conda package."
const conda = true

Repeating the exercise for Conda:

$ find ~/.julia/packages/Conda -iname deps.jl
~/.julia/packages/Conda/kOnIE/deps/deps.jl
~/.julia/packages/Conda/x2UxR/deps/deps.jl
~/.julia/packages/Conda/sNGum/deps/deps.jl
$ cat ~/.julia/packages/Conda/kOnIE/deps/deps.jl
const ROOTENV = "~/.julia/conda/3"
const MINICONDA_VERSION = "3"
const USE_MINIFORGE = false
const CONDA_EXE = "~/.julia/conda/3/bin/conda"
$ cat ~/.julia/packages/Conda/x2UxR/deps/deps.jl
const ROOTENV = "~/.julia/conda/3"
const MINICONDA_VERSION = "3"
const USE_MINIFORGE = false
const CONDA_EXE = "~/.julia/conda/3/bin/conda"
$ cat ~/.julia/packages/Conda/sNGum/deps/deps.jl
const ROOTENV = "~/.julia/conda/3"
const MINICONDA_VERSION = "3"
const USE_MINIFORGE = false

The Conda/sNGum folder is from 2021 and does not specify CONDA_EXE.
The most recent directory, Conda/kOnIE, is from February, before I used mamba (May 15), and before I had this bug.

Should I delete these deps.jl files? I have rebuilt Conda and PyCall many times in the last week without Pkg making new versions of them.

[deszoeke]

I resolved my problem with two steps.

1. I commented out the conda setup that mamba adds to my .bash_profile. It exports a mess of environment variables like CONDA_EXE, prepends ~/mambaforge/bin to the path and runs mamba.sh. Basically, I now run julia in a regular shell not from a mamba/conda environment (not even base).

This did not fix the problem with python dependencies. It might have helped to build the dependencies properly in step 2.

2. I removed the subdirectories .julia/

compiled
conda
artifacts
clones
packages
registries
scratchspaces

Then I was able to add and build PyCall, pyimport("numpy"), ]add PyPlot, and use it.