-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
using CondaPkg with Pluto leads to unnecesarry resolves #120
Comments
@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. |
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. |
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?
The text was updated successfully, but these errors were encountered: