Closed schlichtanders closed 10 months ago
@cjdoris I have resource to create a pullrequest. Would you like to have this changed?
My current thought is that it might be the better approach to extend Pluto with a feature to preserve environments.
My current thought is that it might be the better approach to extend Pluto with a feature to preserve environments.
this was much simpler and already worked out.
@schlichtanders what solution did you arrive at? I'm using Preferences.jl to set a shared Conda environment by default for a package, but the preference is ignored by Pluto, which leads to a minute or more of Conda resolve time every time the notebook is launched.
I have my own fork of Pluto where I now create a hashed project directory instead of a random one. This way I am resolving this issue. Unfortunately I haven't found a workaround without changing Pluto
Do you know if there's already an issue filed in the Pluto repo? I couldn't find one, but I'll create one if it doesn't exist.
I haven't created one. But I probably could extract some parts of my fork in order to solve a respective issue. Can't promise how much time I have though
Hi
I am integrating CondaPkg with Pluto and realized that I have a lot of overhead everytime I start a new Pluto notebook despite all condapkg already being installed.
I debugged it a bit and saw that it is due to a meta file which, if it is missing, triggers a complete reinstall.
The situation for me is that Pluto always creates a fresh new Julia environment (temporary) when opening a notebook. The CondaPkg.toml will be written into it.
JULIA_CONDAPKG_ENV
environment variable, hence the package are indeed preserved and can be found by condaI think two steps would be needed to make the conda resolve work in such Pluto scenario:
What do you think?