create environment in scratch space? about condapkg.jl HOT 4 CLOSED

Yeah I've thought about this before - I agree it would be nice to let the GC clean these up. The issue with scratch spaces is that if your project doesn't have a UUID (i.e. doesn't have a Project.toml) then the scratch space is put somewhere global. I guess we could use scratch spaces in the case there is a UUID and the current behaviour otherwise.

Scratch.jl is used by MicroMamba.jl to store the package cache (root prefix).

from condapkg.jl.

OK, having thought about the scratch-space idea some more, I've concluded that it doesn't make much sense:

• Most of the time, users work in ordinary projects, which do not have UUIDs, so we cannot use scratch spaces for these.
• The exception is if you're developing a package, which does have a UUID. But in this case, we want different versions of the same package to have different conda environments, because they may have different dependencies. So a single scratch space for all versions of the package is not useful.

So I'll stick with the current behaviour of using a .CondaPkg directory under the project directory.

Feel free to reopen if you want to discuss further.

from condapkg.jl.

I hit another issue due to this - when using Bloqade which depends on PythonCall that requires matplotlib in Pluto notebook, since Pluto will initialize the project in temporary directory, CondaPkg seems to be creating the env there too, which does not have executation rights

from condapkg.jl.

(I'll also note that if you delete a project, then since the conda environment is in a subdirectory, then it gets deleted too. So I think the original GC motivation wasn't actually going to help.)

from condapkg.jl.